james-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject Re: [VOTE] Release descriptions
Date Fri, 17 Nov 2006 13:40:27 GMT
I whould like to to do it like MINA do it now. .. Stefano explained it 
very good. So +1

bye
Norman

Stefano Bagnara schrieb:
> I see no one added further opinions (votes!) on this topic, so I add 
> my third reply ;-)
>
> I'm following a similar debate on the mina list and they just agreed 
> on this schema (from http://mina.apache.org/downloads.html)
> =========================
> The version number of MINA has the following form:
> <major>.<minor>.<micro>[-M<milestone number> or -RC<release
candidate 
> number>]
>
> This scheme has three number components:
> * The major number increases when there are incompatible changes in 
> the API.
> * The minor number increases when a new feature is introduced.
> * The micro number increases when a bug or a trivial change is made.
>
> and an optional label that indicates the maturity of a release:
>
> * M (Milestone) means the feature set can change at any time in the 
> next milestone releases. The last milestone release becomes the first 
> release candidate after a vote.
> * RC (Release Candidate) means the feature set is frozen and the next 
> RC releases will focus on fixing problems unless there is a serious 
> flaw in design. The last release candidate becomes the first GA 
> release after a vote.
> * No label implies GA (General Availability), which means the release 
> is stable enough and therefore ready for production environment.
>
> Here's an example that illustrates how MINA version number increases:
> 2.0.0-M1 -> 2.0.0-M2 -> 2.0.0-M3 -> 2.0.0-M4 - 2.0.0-RC1 -> 2.0.0-RC2 
> -> 2.0.0-RC3 - 2.0.0 -> 2.0.1 -> 2.0.2 -> 2.1.0-M1 ...
>
> Please note that we always specify the micro number, even if it's zero.
> =========================
>
> I'm not proposing that solution as-is for James, I just think that 
> their definitions are much less prone to personal interpretation. They 
> define what incompatibilities (changes in the API) need a major number 
> change and that a new feature is a minor number change.
>
> Stefano
>
>
> !EXCUBATOR:1,4555edc653071156412210!



Mime
View raw message