Are we not waiting for Ted's update? I haven't seen any commits come across and I assumed he would do it this weekend....is this still true Ted?
-- 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 1:49 PM Subject: Re: CVS -> SVN / Roadmap > Deal. Roll it James :) > > I'll integrate struts-chain and bring over struts-flow and struts-bsf as > soon James cuts the release and creates the 1.2.x branch. > > Don > > Martin Cooper wrote: > > >On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown <[EMAIL PROTECTED]> wrote: > > > > > >>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.... :) > >> > >> > > > >How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x > >build, then create a 1.2.x branch at that tag, and then roll in the > >chain stuff as the first step on the 1.3.x ladder? > > > >-- > >Martin Cooper > > > > > > > > > >>>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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
