Wow what a long thread and all in the night :-) (well, at least for Europe). Sincerely I don't see the problem of changing the name of "Struts 2.1.x" to "Struts 3.0.x". It's just a version name change. IMHO if you change the API (read: public, protected and package-friendly members) instead of deprecating them, we *cannot* release a 2.1.x version. If we developers are too lazy to deprecate members, well, we either choose to re-create deprecated members, or we should roll a 3.0 version In fact, if we roll out a 3.0 version, Struts users will be sure that these changes are incompatible.
Just my 2 eurocents. Antonio 2008/2/22, Al Sutton <[EMAIL PROTECTED]>: > > 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? > > > Al. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
