[Dev] Milestone numbering going forward

[Bryan Stearns]

-1 to this 'forward' numbering scheme: I voiced an opinion earlier today 
in IRC that this numbering scheme is confusing, but Heikki said it had 
already been decided.

Every project I've worked on works the old way: intermediate builds have 
a number based on the previous major release, with something incremental 
added to it. The only exceptions to this are release-candidate builds 
(which aren't done unless they're _really_ release candidates: the only 
way a build gets tagged with 1.0-RC-something is if people believe it 
might actually be the build that gets tagged 1.0).

It seems wrong that 0.7 is going to sort before all of the intermediate 
builds that lead up to it.

(more below)

...Bryan


Heikki Toivonen wrote:

>Many people have complained that the current milestone numbering scheme
>is confusing and unworkable. The current system is simply ascending
>numbers with major, minor and micro revisions, where the micro revision
>is padded with a leading zero if it is less than 10 (to help sorting).
>So for example, these milestones would happen in this order: 0.5,
>0.5.01, 0.5.02, 0.6.
>
>Some problems that have been mentioned with this system (I may be
>forgetting some):
>
>* Doing a bug fix release of a milestone/release would need to add
>fourth group of numbers, which seems excessive. For example, if we'd
>need a bug fix of 0.6 release, it would have to be 0.6.0.1 to
>distinguish from 0.6.01 milestone on the trunk (and even then there
>might be confusion because of the leading zero).
>  
>
I don't see how the confusing forward-numbering scheme affects this. How 
does it solve this problem?

>* It's hard to talk about a milestone with these major, minor and micro
>numbers. The informal way to talk about the milestones has been to say
>m<some number>, which means the the <some number> micro revision in the
>current  release cycle. So currently m8 would mean 0.5.08. But this is
>informal, and changes meaning once we switch focus to the next release.
>  
>
Again, the forward-numbering idea still has us talking using major, 
minor, and micro numbers. How does it solve this problem?

>* Some people would like to use the Bugzilla version field to mark the
>version of Chandler in which the bug was found. This is clear enough
>with a release, but unclear with the current numbering when working
>towards a release. Should the version currently be 0.5 (the previous
>release) or 0.6 (the release we are working towards)?
>  
>
The bugzilla "build identifier" field should be used to record the 
specific build where the bug was found.  The version number field is too 
limited to be useful, and the guided bug-entry page doesn't even ask for 
it separately anyway... further, I again don't see how numbering forward 
helps in this case: reporters need to record the specific build in which 
they found the bug no matter what nomenclature we use.

>I think Aparna, Philippe, Sheila, Ted, Katie and me then sat down to
>create another numbering scheme that would fix those shortcomings. It
>was decided we'd go with the following:
>
>The major and minor versions are to be the release we are working
>*towards*, and the micro version would be of the form m<ascending
>(milestone) number (in current release)>. So, currently we are working
>on 0.7.m1 on the trunk. After that will be 0.7.m2 and so forth, until we
>finally hit the 0.7 release. Then we'll start work on 0.8.m1 etc.
>