qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: Release numbering suggestion
Date Tue, 22 Dec 2009 16:53:01 GMT
Alan Conway wrote:
> On 12/22/2009 10:43 AM, Andrew Stitcher wrote:
>> We currently have a problem distinguishing between the qpid release
>> numbering for actual releases and release branches and code development
>> on trunk.
>> For example before starting the 0.6 release the label 0.5 was ambiguous
>> - it referred both to the development code on the and the code in the
>> 0.5 release. By that I mean that the code on trunk thought it was 0.5
>> too and reported that.
>> I propose that we change the trunk numbering to 0.7 at the point we
>> branch 0.6 for release.
>> Then I propose that we change the numbering to 0.8 when we start the
>> next release process.
>> Then we would change trunk numbering to 0.9 when branching the next
>> release etc.
> 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.

This would remove the ambiguity and we should make sure to do this at a 

>> 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?
>> Minor disadvantage: Our releases skip from 0.6 to 0.8 to 0.10 etc.
>> Comments?
>> [unless I hear heated opposition by the actual point of release, I will
>> do this]
> Not heated opposition, I'm just not understanding the benefits.

The benefit is being able to easily distinguish between a random 
development version of the code that is in-between releases and a 
version of the code that is in close proximity to a release (either just 
before a release or just after).

Basically we can choose to bump version numbers just before releases, 
just after releases, or both.

I think at a minimum we need to always bump just after releases. Other 
than that I'm fairly relaxed, although I can see the appeal of bumping 
both before and after.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message