struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: API Compatibility
Date Fri, 22 Feb 2008 14:54:38 GMT
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:


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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message