[Dev] Milestone numbering going forward

[Aparna Kadakia]

Bryan,
This proposal to change to the current milestone/release numbering 
scheme was initiated by me in the first place. And I had a number of 
reasons for that as listed below by Heikki. The current numbering scheme 
suffers from drawbacks which mostly affect release management and QA.
See my comments inline..

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?

[Aparna]: The forward numbering scheme does indeed solve this problem 
because the trunk would be numbered 0.7 onwards whereas the branch 
releases will continue as 0.6.01, 0.6.02 etc. This would be lot less 
confusing than having trunk on versions like 0.6.01 and the branch on 
0.6.0.1

>
>> * 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?

[Aparna]: Well atleast we will all be on the same page when saying we 
are in m8 milestone. Currently we say we are doing milestone m8 but the 
builds are called 0.5.08. We actually had problems where people couldn't 
connect the two and led to some miscommunication. This is mostly to keep 
terminology consistent in our communication.

>
>> * 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.

[Aparna]: This is one of the main driving forces for this proposal. 
Having the build identifier is useful in some sense but it doesn't in 
any way tell you which release version this bug was found in. For e.g. 
our current build identifiers look like : 
Chandler_win_20051129191940.exe but it would also be helpful to know 
which release we were working on when this bug was found. This 
information would be very useful for QA.
Since Version field is one of the fields for in bug entry form most 
people(internal and external) are likely to set the field to some value 
and currently they are either being set to  0.5 (since that's what our 
build numbers say for milestones)  or 0.6 because that's the release 
version we are working on. So there's tremendous confusion there. This 
would be even more critical once we branch we have bugs being filed on 
the 0.6 branch v/s the 0.7 trunk. Also, setting the version field 
correctly helps us to track number of bugs filed/resolved/verified for a 
specific release and do some data analysis based on that. Currently we 
have to resort to querying based on dates.

Anyways, adding the version number is just more information in the bug 
report, which if not to anyone else, is helpful to QA.

I am definitely voting +1 on this.