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. Andrew --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
