[Dev] Milestone numbering going forward]

[Andi Vajda]

+1 to Bryan's objection. 1.0.m1 is far from 1.0, calling it 1.0 is false
advertising.

Andi..

On Tue, 29 Nov 2005, 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
>