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