IT RFE: Figure out a way to implement procedural usage of the milestone
Martii opened this issue · comments
In reference to this statement...
sizzlemctwizzle wrote:
I'm not crazy about version numbering for GM_config, so I'd say 2. Only bump it when there is a significant change in behavior (this issue would constitute that). And only change the major version for massive changes (like what went into v3).
... figure out a way to implement usage of the milestone feature of the issues portion of Github. As all of us have various duties to attend to and it would be helpful to have this "goal reminder" used besides using a label and better grouping of issues resolved in a particular "release".
Throwing out some ideas:
- MD5 hash versioning isn't predictable.
- I'm not sure a projected "deadline date" would work well or even go over well.
- Version "next" wouldn't help grouping a list of what was changed as this could get rather large.
I am definitely open to suggestions.
My best guess is that until we decide exactly what should go into a major release (i.e. 4.0), we use minor milestones to denote progress (like 3.1). We keep adding more issues into that minor milestone until there is enough on our plate, then we use the next milestone (like 3.2) for stuff we'll handle later. Then long term stuff should be put at some remote milestone (like 3.5). We can also put things off to later milestones if we think a minor release is complete.
Sounds good. Now do we want "pre" or "post" increment? What this means is kind of complicated for me to explain.
With gmport I've been finding Anthony has been changing back and forth between when he version bumps. Sometimes it's before a series of changes. Other times it's after. Since this project isn't nearly as complicated as GM itself I am not sure that pre bumping may be necessary but I wanted to run this by everyone anyways for ultimate clarification. Pre bumping makes it harder for us to diagnose what is going on with an issue, in my opinion, since current "release" is usually this repos HEAD. If you look at GM upstreams latest commit it's actually after 1.13beta6 so technically the upstream repos HEAD is 1.13beta6 + "next".
Pre-increment. So we are in v3.1 right now. Since the latest version of GM_config is downloaded when a script is installed (unless the script writer points to a particular commit or a script isn't updated in a long time), we can assume their problem is with HEAD. We can always tell them to reinstall the script just to be sure. Does that make sense?
Since the latest version of GM_config is downloaded when a script is installed (unless the script writer points to a particular commit or a script isn't update in a long time), we can assume their problem is with HEAD. We can always tell them to reinstall the script just to be sure. Does that make sense?
Yes.
Pre-increment. So we are in v3.1 right now.
Okay :) Thanks for the clarification. gmport vs GM has been driving me crazy with toggling back and forth and I wanted to make sure we had a clear plan here.
Closing as "defined".