On Wed, 13 Oct 2004 06:26:00 -0400, Ted Husted <[EMAIL PROTECTED]> wrote: > On Tue, 12 Oct 2004 15:22:38 -0700, Martin Cooper wrote: > > That said, I would really like to see us all stick together for as > > long as possible, and not diverge into 1.x and 2.x paths too soon, > > simply because I don't think there is enough energy here to sustain > > two parallel version of Struts. > > Apache teams have had that discussion before. In practice, parallel development > creates more energy. People don't work on open source just because it is there. They > do it because they have an itch to scratch. People are running out of 1.x itches. A > 2.x codebase is not going to "steal" hours from 1.x. The hours people would put into > 2.x are not being put into 1.x now. >
I think this depends on how we're defining 1.x. If 1.x is simply a maintenance branch, then I agree that there's not going to be a lot of energy put into it. However, if 1.3.x is where we move to Servlets 2.3, push struts-chain into the mainstream, factor out file uploads, separate Tiles, and those kinds of things, while 2.x is the purview of those fortunate enough to be able to use Servlets 2.4 containers, then I really do think that we'll split the community unless we do the bulk of these things before we split off the 2.0 version. The bottom line for me personally is that I want (to contribute to) revolution more than evolution, and I need it to happen in a way that I can use it on Servlets 2.3. If we have two parallel development streams, where X is 2.3 compliant and Y is 2.4 compliant, I don't want to have to spend my time back-porting all the cool stuff some people are putting into Y just so that I can use it on a 2.3 container. (I don't really care what the numeric values are for X and Y.) And I don't think we can sustain revolution on more than one version at the same time. > So, I do want to encourage people to diverge into 2.x, since there is not enough > energy to sustain 1. x alone :) > > This is not to say that 1.x would go dormant. I'm sure there are things people still > want to there, and I'll continue to apply patches to fix whatever problems people > find. > > > > And what I'm saying is that I don't see a reason to make the > > provision (i.e. create /v1) until we know we need it, because it > > would be just as easy to create then as now. > > As easy to create on the server, but there'll be a lot of churn on the client. > Better to get it over with now and give the project room to grow. > I disagree. The only "churn" on the client is that people have to check out a new tree. That's something people do all the time already, so it's no big deal. On the other hand, your proposal means that, as I understand SVN at least, I will lose the ability to have SVN help me copy, merge, move, etc. between /v1 and /v2, since they have separate and independent 'trunk' directories. To me, that has a *much* greater impact overall than just making someone check out a new tree at some point. And, as I've said elsewhere, like Craig, I'd prefer to use branches instead of whole new trees in any case. -- Martin Cooper > > > -Ted. > > --------------------------------------------------------------------- > 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]
