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!
