I favor a evolutionary approach to getting to the Next Generation of Struts. As apposed to scrapping every piece of code we have. This would entail aggressively deprecating functionality.
I believe the plan was to do both. Work can continue on Struts 1.x.x to evolve it into an even more useful framework. Meanwhile, work on a new codebase for Struts 2.x.x can also proceed.
Of course, when people say "new codebase", I don't think we mean a cleanroom implementation. There would be lots of reuse of code that already works well.
The relationship between the branches is liable to be synergistic. In evolutionary mode, it's sometimes hard to see the forest for the trees, and in revolutionary mode is sometimes hard to see the trees for the forest :)
In the end, whether Struts 1.x.x evolves into Struts 2.x.x, or whether Struts 2.x.x emerges from a revolution, will be up to Darwin. The volunteers will elect to spend their time on this or that, and whichever approach proves more attractive will win.
In the meantime, it's important to avoid saying whether a given codebase will be 2.x.x or not. When the time comes, the community can decide, but we'd need a working 2.x.x candidate in front of us first. :)
http://incubator.apache.org/learn/rules-for-revolutionaries.html
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
