[Dev] Milestone numbering going forward

Heikki Toivonen heikki at osafoundation.org
Tue Nov 29 22:47:45 PST 2005


Aparna Kadakia wrote:
> Bryan Stearns wrote:
>> Heikki Toivonen wrote:
>>
>>> * 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

Well, at some point we would still have 0.7.1 and 0.7.m1. Separated by
quite a bit of time, but still we would have them.

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

This is not actually the build identifier. That is the name of a
Chandler installer for Windows, built by the continuous build process.
You can't tell from the name if it will install a branch build or a
trunk build, for example. The series of numbers is just the timestamp
when it was done.

The build identifier is available from the Help > About Chandler menu.
It looks something like this:

Version: 0.5-7 (rev 8152 build Milestone_0.5.07)

i.e. it has a Chandler version number and a Subversion revision number.

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

I disagree with this, since the version number does not in fact convey
all the necessary information - it's the build identifier that does.
Unfortunately there is no field for that in the bug database, so it just
needs to be part of the freeform comment (the guided bug entry form
specifically asks for it).

In the Mozilla project the version field is generally not used. The full
user agent string (equivalent to our build id) is used instead (for the
browser products at least).

-- 
  Heikki Toivonen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20051129/4a061bd9/signature.pgp


More information about the Dev mailing list