qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Release numbering suggestion
Date Tue, 22 Dec 2009 18:18:10 GMT
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:dev-subscribe@qpid.apache.org

View raw message