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]
