> 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.
I agree with that, because it is then hard to tell if you're looking at the release or something later in the dev stream. > > > 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. But what's a dev "version"? The only time you can really have a meaningful "version" is when it's tagged and set aside. Dev stuff is a moving target. Any given number assigned to "dev" today is not the same as tomorrow's. What does it mean to schedule a fix for "dev"? -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
