Up to and including release 4.0, Tapestry numbering was "marketting driven". Every release was no backwards compatible to the previous release, and the numbering was basd on marketing reasons, rather than API compatibility.
To what degree are these new releases NOT backwards compatible with the previous release? On 5/1/06, Brian K. Wallace <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I know I'm sounding like a broken record, but here goes... With what's going into 4.0.3 (and 3.0.5, but that doesn't appear to affect anything if we bump to 3.1) as far as new features that are backward compatible, wouldn't 4.0.3 be better suited as 4.1? This would make the current 4.1 better as 4.2? Are all the changes in the current 4.1 backward compatible? Or would 4.1 be better as 5.0 - making the current 5.0 better as 6.0? Not trying to mess with anyone's ideas, just trying to stay coherent in our releases and give users proper expectations of our releases. [and believe it or not, I don't post unless I think it affects more than just me] Thoughts? [does anyone care? ('care' to be meant in the spirit of "numbering's fine as is")] Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEVg+7aCoPKRow/gARAi+4AKCNeb0R0pzcoOT1MWd8so1dNaD9sgCg1AY1 oPRDTtTZ3xe9buu2u+2Qv4c= =Ena2 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]