On 12/22/2009 12:06 PM, Andrew Stitcher wrote:
On Tue, 2009-12-22 at 11:37 -0500, Alan Conway wrote:
...
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.
I could certainly accept that. What I think is wrong is leaving the
trunk with the old release number until starting the next release
process.
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?
Well partly it's precisely because it allow you to tell at a glance
whether a bug report is against a released version of qpid or against a
devel version of qpid.
I think the major advantage of distinguishing between release/dev
versions is in bug reporting and scheduling bug fixes.
I have to say that I think these are enough to make me want to do it,
but not enough that I'm totally attached to the even-odd thing.
Another point is that a number of other projects do distinguish between
dev and release versions using precisely this model - it's not a proof
that it's any good for us, but an indication that it's useful for them.
OK, sounds reasonable. No objection from me.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
