james-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [VOTE] Release descriptions
Date Sat, 11 Nov 2006 15:34:56 GMT
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


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


View raw message