+1 Let's stick to the roadmap we laid out in July.
http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: >�On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein >�<[EMAIL PROTECTED]>�wrote: >>�Forgive my possible ignorance, but what is the policy on new >>�releases? I've understood that we can release whenever we want, >>�that version numbers are cheap and that you vote whether to make >>�a release alpha/beta/GA. But, what goes into a release? Does new >>�features/enhancements go into a 1.2.x release, or is it strictly >>�bug fixes? >> >> >�What we've talked about before is along these lines: > >�Within the 1.2.x series, it's fine to fix bugs and add new stuff, >�but not fine to make any backwards-incompatible changes. > >�For a 1.3.x series, we could be more liberal about adding new >�stuff, and possibly have some deprecations in 1.2.x that get >�removed -- but it shoujld in general be based on similar enough >�architectural principles that there be a clear upgrade path. > >�The challenge, of course, is when do you make that split for the >�evolutionary path? �I'd say that something as fundamental as using >�Struts Chain instead of the monolithic RequestProcessor, and the >�other changes we could make as a result of having that, would be >�good grounds for a 1.3.x series. �If that were to start in the >�short term, then thinking of 1.2.x as being in maintenance mode >�seems likely (although if there's willingness to port features back >�and forth, it need not go that way immediately ... for example, >�Tomcat 4.1.x continued to develop for a little while at the >�beginning of 5.0.x, including some features ported back and forth, >�but this pretty much stopped as soon as there was a solid 5.0.x >�release for people to use). > >�For a 2.x chain, we could have the freedom to be somewhat more >�aggressive at rearchitecting ("if we'd known then what we know now, >�what would Struts have looked like?"), and could in theory have a >�series of alpha releases in parallel with stable releases on 1.2 or >�1.3. �As others have pointed out, how much simultanaeity there is, >�and how often releases happen, is more based on the directed energy >�of the committers (and what they want to work on), and less on >�whether there are parallel development efforts going on. > >>�The reason I ask is because I would love releases much, much more >>�often, but as have been pointed out, incompatibilities/quirks >>�between minor versions could be a disaster. >> >> >�Historically, I'd say our 1.0 ->�1.1 transition was, in terms of >�interoperability and upgrade, a bit on the edge of what most users >�liked, while the 1.1 ->�1.2 transition was much easier to do. �We >�haven't actually gotten around to many x.y.z releases on 1.0 or >�1.1, so having them happen at all in 1.2 should be a refreshing >�change :-). But I agree with you that compatibility is especially >�important within an x.y release cycle. > >>�\Anders >> >�Craig > >�-------------------------------------------------------------------- >�- To unsubscribe, e-mail: [EMAIL PROTECTED] For >�additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
