[Dev] Milestone numbering going forward

[John Anderson]

+1 to Bryan's comment

Bryan Stearns wrote:

> -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.
>>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev