If you just refer to "build.xml" the docs should apply to a branch as well as they apply to the trunk. But it's worth mentioning "trunk" in the context of what URL you use to check out the repository in the first place.
Craig On Thu, 14 Oct 2004 12:23:42 -0700, Don Brown <[EMAIL PROTECTED]> wrote: > I don't mind making those CVS to SVN documentation updates today. One > question though, are we assuming people checked Struts trunk out or the > entire Struts repository? This affects whether we refer to a file as > "trunk/build.xml" or just "build.xml". > > Don > > Martin Cooper wrote: > > > > >On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell <[EMAIL PROTECTED]> wrote: > > > > > >>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? > >> > >> > > > >Yes, we should wait for Ted's updates. We do need to get the docs > >switched over to talk about SVN rather than CVS. > > > >-- > >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 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] > >> > >> > >> > >> > > > >--------------------------------------------------------------------- > >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]
