On Thu, 14 Oct 2004 12:50:49 -0400, James Mitchell <[EMAIL PROTECTED]> wrote: > Ted, I will roll a release as soon as you say 'go'. > > If you and/or Martin (or anyone else that has time and patience to deal with > me) could help with questions wrt label/branch/etc.
I should be around this weekend. You know where to find me on IM. ;-) -- Martin Cooper > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > > > ----- Original Message ----- > From: "Don Brown" <[EMAIL PROTECTED]> > To: "Struts Developers List" <[EMAIL PROTECTED]> > Sent: Thursday, October 14, 2004 11:30 AM > Subject: Re: CVS -> SVN / Roadmap > > > Ted Husted wrote: > > > > >+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. :) > > > > > > > > +1 I vote we (or perhaps I specifically) integrate struts-chain this > > weekend. It is stable, and I've been using it in production for some > > time without problems. Course that also means we (again, perhaps I > > specifically) should release commons-chain 1.0. Ted, there are a few > > Guinnesses in it if you help me with the documentation.... :) > > > > >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 :) > > > > > > > > Ah, Guinness - the ultimate currency. You got yourself a deal. > > > > Don > > > > >-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] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
