> -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] ==////== > > On 7/31/05, Nick Heudecker <[EMAIL PROTECTED]> wrote: > > > I think there are a lot of people out there who feel as > you do, but > > > backwards-compatibility has always been a major theme for those > > > > While backwards compatibility is nice, I would rather see a better > > framework for the 2.x release. My personal opinion is that version > > compatibility should be required between point releases, > but all bets > > are off for major revisions. > > I would tend to agree. > > Personally, I think a great place to start would be a Struts codebase > for Java 5. It's not something I can work on myself right now, but if > I start coding in Java again, I'd definately want to get up to speed > with everything that Java 5 has to offer. > > A lot of frameworks that are very different from Struts are able to > read the Struts configuration and allow use of Struts actions and > such, while also allowing use of the native framework members. > > But any proposals for a new Struts subproject or revolution have to be > based on an existing codebase. Discussions and debates will never be > enough. Someone has to show us the code, and more importantly, the > community behind the code. >
Yes I tend to agree that just discussions is not equal to code, but one must have "the vision", and for a vision you must eventually come up with a design. > When a coder is a committer, like Craig or I, we can start whiteboards > in the Apache repository, mainly to avoid putting the code through the > Incubator later. But, we still have to go through the same guantlet > with the Struts PMC that a codebase that originated at SourceForge > goes through. > > What we want to most in a proposal is an indication that the project > will go on whether Struts accepts it or not. We want codebases that > can stand on their own feet, but would prefer to stand with us, if > they can. If the only way a codebase will get written is if we accept > it, then the codebase will never be written :) > > Every major codebases we've ever accepted, Validator, Tiles, Nesting, > EL, Scripting, Flow, and Shale, were all written and attracting > communities before we considered them for subprojects. And, had we > passed, each one of these would have gone on to live indepedant lives > with their own communities.. So what you saying one can take the existing codebase and build a next generation derivative. Publish it around, wait for the community to build up, and then you will get a chance to be considered among equals. > > HTH. Ted. > ==////== -- Peter Pilgrim :: J2EE Software Development Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.csfb.com/legal_terms/disclaimer_external_email.shtml ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
