On Wed, 2004-10-13 at 23:18, Martin Cooper wrote: > 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.
Personally, I think 1.3.x should include everything you listed above. I think 2.x should be a strong move to (1) Java 5.0, (2) J2EE >= 1.4 In my opinion 2.x should be designed around new capabilities, and design trends. 2.x should make Struts - leading the way again. Most of what I've heard so far on this list and in the (280+ open issues, which are mostly enhancement requests) are changes that fit the 1.3.x mold. Flow control can stay the same, while we adopt chain as the primary request processor, without breaking backwards compatibility so I think that is a 1.3.x feature. Same goes for the other things that were mentioned. Perhaps to signify it is a significant change but still same design, it can be versioned 1.5.x (nicknamed 5.0 to spoof Sun :-) As for the SVN trunks and branches: - leave 1.3.x at the trunk. focus efforts there, while discussing, white boarding, and planning 2.x. (Like I said, most of what I've heard/read so far is 1.3.x) - when planning is complete and code is starting to be contributed create a 2.x branch. - when the branch starts to stabilize (which may take some time ;-) and focus starts to shift to 2.x development, make 2.x the trunk and the 1.x (trunk) to a branch. The head/trunk should be primary development. branches should be used for two things - radical changes that should be done in parallel as not to conflict with primary development, and for maintenance versions and back porting Subversion makes moving between trunk and head, copies, etc. "cheap" and painless. The trunk is really another branch, which is really just a tag, which is really just a build number alias. Creating copies/branches/tags - are essentially just creating an alias to single build. Since builds are atomic, a build is the entire snapshot. Which is one of the many reasons subversion rules. Every commit is essentially a tag and branch. Because of this you also get the great gift of true history - no matter how you refactor, move, or copy files or folders around, you always have version history going back to were it originated. (and since it is all done with pointers and meta data, folders are files are props). Welcome to Subversion! I don't think a 2.x branch should be created until there is some more planning. We need consensus on 1.x future and 2.x goals. There is still a lot of room for 1.x revolution. It is a good design, and with minor changes can become even more flexible and powerful. scratching a lot of itches. I don't think it should be labeled maintenance. 1.2.x is maintenance. There is a lot you can do with the current framework to (1) excite developers, (2) improve productivity and efficiency of struts application development, (3) increase flexibility and plug-ability through refactoring - chain is a great example of this. next stop forms improvements, (4) prepare for 2.x, and last but definitely not least (5) have fun developing it. In my opinion, were 2.x should be radically different is in the areas of: - configuration - wiring of components - container agnostic (servlet, standalone application, junit test, whatever) - use of latest greatest specs and tech (5.0 features including variable args, meta data/attributes, and typed enums) One thing I haven't mentioned yet, was momentum and timing. I don't think it is the right time or the right momentum to start 2.x coding. There is more MVC framework competition in the industry than any other year. Developers have a hard time keeping up with the new changes. A market place like this creates 2 things - buzz and demand for new techniques, and overwhelming reluctance to change. Struts is the defacto standard, but is starting to look dull to many people. I think this is only true because there are strong demands currently for unit testing, dependency injection and pluggable object factories/registries (ioc containers). I feel all of these can be supported in 1.3.x without changing backwards compatibility. I feel these changes can put momentum back into Struts. The momentum should be there prior to 2.x. Of course the other side of the coin, some will argue that 2.x will bring the momentum. This may be true, but I feel that the timing will make it just another "new MVC" and you the community will be faced with an overwhelming reluctance to change. This will result in a fragmented community. Bottom line: my vote is - lets rock the industry with a revolutionary 1.x release, start discussing goals and planning of 2.x build, and start developing and stabilizing a 2.x after the next 1.x release I'm not sure what everyone's experience is (i know some of you are soldiers and some lieutenants, and some bosses.) - struts needs everyone. For anyone contributing to the design and planning, I do suggest researching other MVC frameworks. I've been in this space for about 5-6 years now and have a lot to contribute. If you have any questions about any frameworks raise them here. Also, if you see something you like speak up about it. I'm familiar with: Struts, Turbine 2.x, Turbine 3.x, Cocoon, WebWork, ASP.NET, Tapestry, Spring MVC, and various other patterns in various languages. All have there benefits, and all have there faults. > > 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]
