On 12/22/2009 10:43 AM, Andrew Stitcher wrote:
We currently have a problem distinguishing between the qpid release
numbering for actual releases and release branches and code development
on trunk.
For example before starting the 0.6 release the label 0.5 was ambiguous
- it referred both to the development code on the and the code in the
0.5 release. By that I mean that the code on trunk thought it was 0.5
too and reported that.
I propose that we change the trunk numbering to 0.7 at the point we
branch 0.6 for release.
Then I propose that we change the numbering to 0.8 when we start the
next release process.
Then we would change trunk numbering to 0.9 when branching the next
release etc.
How about we change the number to 0.7 when we branch 0.6, and leave it 0.7 when
we release 0.7. There's no ambiguity: 0.7 refers to the code that will someday
be release 0.7 up to the day it actually becomes 0.7.
The advantage of this scheme is that it is immediately obvious whether a
given release is development or a released release (odd numbers are dev,
even are release). It also means that the numbering is never shared
between trunk and a branch.
What's the purpose of a separate version number for in between releases?
Minor disadvantage: Our releases skip from 0.6 to 0.8 to 0.10 etc.
Comments?
[unless I hear heated opposition by the actual point of release, I will
do this]
Not heated opposition, I'm just not understanding the benefits.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
