The problem with the method you mention is that with the apache release
voting system we don't know the quality of the release until after it's been
made and voted on, so we can't release an "alpha" version because until the
vote has happened it may turn out to be a full release.
I also believe it's down to the tool to accommodate the releases of the
project, and we shouldn't define a release numbering system around what
suits any particular tool.
Al.
----- Original Message -----
From: "Brian Pontarelli" <[EMAIL PROTECTED]>
To: "Struts Developers List" <dev@struts.apache.org>
Sent: Friday, February 22, 2008 2:54 PM
Subject: Re: API Compatibility
Al Sutton wrote:
Just so we're all on the same page, can I put forward the following as a
version numbering plan which would seem to reflect most peoples views;
2.0.x - New releases shouldn't alter the public API unless absolutley
neccessary (e.g. something is a security risk).
2.1.x (pre-first GA) - Changes to the public API allowed, all pre-first
GA releases are evolving and are released to allow users to get a feel
for the direction 2.1 is going in and comment on it in the users list.
2.1.x (post-first GA) - New releases should not alter the public API
unless absolutley neccessary (e.g. something is a security risk).
2.2 - Needed if there are post-first GA 2.1.x changes which will break
parts of the public API and the changes are only functional enhancements.
3.x - Only needed if there are changes to large parts of the public API
which would break almost every S2.x app out there (in the same way the
1.x to 2.x did).
Does this sound OK?
This scheme doesn't work because you can't tell a tool generically how
things are compatible. The scheme needs a method for doing release while
still breaking compatibility. This is where traditionally libraries tend
towards alpha, beta, milestone and release candidate numbering. Savant
uses this model:
1.0-Ax
1.0-Bx
1.0-Mx
1.0-RCx
1.0
1.0.x
1.x
In order to support the current model you would need to tell tools like
Savant and Ivy that 2.1.0 is not compatible with 2.1.1 but 2.1.1 is
compatible with 2.1.2. In essence you would need a file that lists the
compatibility that those tools could use when verifying the project.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
