Hi, I'm not against but I think you took 2.5 too literally ;-) Basically we can merge plans for 2.5 and 3.0 and start coding. But even with directly targeting 3.0 we still have to resolve a lot of code unrelated issues - where to move deprecated plugins (and how without losing history of commits)? should we separate plugins from Core (how to manage version cross matrix)? what to do with webpage (documentation, wiki uses code snippets, should we continue using Confluence)? does our current git flow model is efficient (I have some doubts)? and so on ...
I'd like to treat 2.5 as a milestone (and specify other milestones), as we can always stop, tag the source code and prepare a release candidate. I'm bit afraid working on 3.0 as there is many other things that must be resolved - that's why I wanna do it step-by-step and testing/resolving one code unrelated issue in that time as well. Another thing is that if we gonna release some intermediate versions, there is higher probability that someone will use it and test it for us - will migrate not do a new app from scratch ;-) So as you see I have some doubts that I'd like address them before we start making new branch and renaming packages to org.apache.struts3 ;-) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2014-11-19 19:20 GMT+01:00 Johannes Geppert <jo...@apache.org>: > Hi, > > what you all think about starting with Struts3 and creating a brunch > directly after next 2.3.x release and create only maintenance releases for > Struts 2.3. > > I personal think we should skip plans for 2.5 [1] and better concentrate on > creating a new major release. > > > Best Regards > > Johannes > > [1] https://cwiki.apache.org/confluence/display/WW/Struts+Next > > > ################################################# > web: http://www.jgeppert.com > twitter: http://twitter.com/jogep --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
