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 16:37:09 GMT
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.

>
> 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.

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


Mime
View raw message