That would be a good idea to follow MAJOR.MINOR.MAINTENANCE.PATCH approach, it's clear and reasonable for the users and for us. I would say, let release 2.3.x and start thinking about 3.x, what should be in, what out and so on.
Struts NG isn't a good name for me, Struts NG 3, Struts NG 4, ... Struts 3, Struts 4 is far better ;-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ 2011/10/14 Rene Gielen <gie...@it-neering.net>: > After getting things a bit sorted out on my side, it looks like is not > exactly a need to deprecate 2.1.x, since it is not marked as a > maintained branch anywhere - especially on the download page. > > As for 2.0.x, the reason why it is still marked as a maintained branch > and "best available" release is that the differences between 2.1.x > (introducing plugins and source code breaking changes) and 2.0.x led to > 2.0.x being maintained for a while, including applying important bug and > security fixes. Fact is, though, that no one seems to be maintaining it > any longer - especially regarding security it lacks serious fixes. > > So if there is anything to deprecate, it should be the 2.0.x branch AFAIC. > > For branches like 2.1.x, which simply got replaced by newer releases, we > might want to make it more clear to users that they should try to stay > with the most recent "non-breaking" releases rather that with > unsupported versions such as 2.1.x. > > That said, I think we are lacking a decent versioning scheme that helps > users to decide what to do. We got into that situation by coining the > term "Struts 2" as kind of a brand, which narrowed our versioning scheme > significantly. If we weren't nailed to staying with the 2 in front, we > might have had more reasonable versions like > 2.0.x > 2.1.x -> 3.0.x (breaking changes) > 2.2.x -> 3.1.x (non-breaking, serious improvements though) > 2.3.x -> 3.2.x (again non-breaking) > 3.x -> 4.x (major refactorings, breaking API changes) > > Thus we would have had an easy to understand scheme of > MAJOR.MINOR.MAINTENANCE[.PATCH] > whereas MAJOR indicates API changes (vice versa, stability), MINOR new > features and improvements, MAINTENANCE bug fixes and PATCH mostly single > and urgent security fixes. > > At last for the next breaking change release, we should be clear what to > do. The version term 3.x was already coined, so do we feel good with > giving up the "brand" Struts 2? Do we want to call it "Struts 2, version > 3.0.whatever"? Do we feel like renaming "Struts 2" to "Struts 3", > although this might cause some user expectations as if the shift from > "Struts 2" to "Struts 3" would be as groundbreaking as the shift from > "Struts 1" to "Struts 2", which of course isn't quite the case? > > What are your thoughts? > > - René > > PS: Gee, "Struts NG" wasn't such a bad naming suggestion at all ... :) > > Am 11.10.11 21:59, schrieb Maurizio Cucchiara: >> Hi guys, >> As René pointed out (see http://s.apache.org/2hn) we should seriously >> take into consideration to deprecate 2.1.x version. >> Another thing that I have just noticed is about the full releases >> present on the download page (http://s.apache.org/GFV): why there is a >> 2.0 version and not a 2.1? >> We are going to release 2.3, so I think is the right time to afford this >> topic. >> >> I guess we should open up a vote. >> >> Twitter :http://www.twitter.com/m_cucchiara >> G+ :https://plus.google.com/107903711540963855921 >> Linkedin :http://www.linkedin.com/in/mauriziocucchiara >> >> Maurizio Cucchiara >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
