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. 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.. HTH. Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
