qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: Release numbering suggestion
Date Tue, 22 Dec 2009 17:06:32 GMT
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-subscribe@qpid.apache.org


Mime
View raw message