[Dev] Milestone numbering going forward

[John Anderson]

Alec Flett wrote:

> Aparna Kadakia wrote:
>
>> [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
>>
> I have to agree with heikki here - when 0.7 goes out the door its just 
> going to get confusing again. because we'll have 0.7.m1 and 0.7.1 and 
> they'll be very different builds. And what do we call the intermediate 
> builds after 0.7 and leading up to 0.7.1? "0.7.1.m1"?  Its confusing 
> either way. All we've done is delayed our confusion from the beginning 
> of the 0.7 milestone to the end of the milestone, when we'll have to 
> have this debate again.
>
> So here's my vote on this:
> 1) if we go with a backwards numbering system, then we use "M" - 
> 0.6m1, 0.6m2, ... 0.7. This allows us to release a 0.6.1 (lets say, 
> hypothetically for PyCon 2006 we might need to tweak the branch for 
> some development work..)
> 2) if we go with a forwards numbering system, then we use "alpha" or 
> something to indicate that we're leading up to the release - 
> 0.7alpha1, 0.7alpha2,...0.7.
>
> In either of these schemes, I would love to also see subversion 
> revision numbers (r8403) added to the version.. (0.6m1-r8403 or 
> 0.7alpha1-r8403)

+1 for including subversion revision numbers

>
> Alec
>
>>>
>>>> * 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.
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>
>
>------------------------------------------------------------------------
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Dev" mailing list
>http://lists.osafoundation.org/mailman/listinfo/dev
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/dev/attachments/20051130/32837342/attachment.htm