I'm OK with this, from an end user perspective certainly, and from a
(sort of I guess) framework developer as well.
However, you raise an interesting point in my mind...
"Struts Action 1.x will continue to be developed actively"
Ok... I personally like that. However, why wouldn't it also be said
that "Webwork 2.x.x will continue to be developed actively" too? You do
mention continuing to apply patches, but that's different.
The reason I ask that question is this...
There are a lot of API changes being bandied about. Some are minor,
some possibly major. If ever there was a time to "get it right", so to
speak, and in the process break backwards-compatibility, I would think
now is the time. Especially when the proposal includes active
development of an old branch, so no one is "left behind", why not say
the same for Webwork, and then drop the idea of compatibility for SAF2
entirely?
Obviously there has to be people in the Webwork community willing to do
that too.
I think that would focus resources first of all... those that are
working on SAF2 can do so without concern for SAF1 or even Webwork 2.x.x
compatibility. Secondly, it would allow all the "revolutionary" ideas
to be included without issue.
Now, you might argue that keeping compatibility brings the existing
communities along, and I don't disagree. But, isn't that negated by
making it official "policy", as it were, to continue developing the
older branches as well? The community isn't being "left behind" in that
case.
You might also argue that keeping compatibility, to the extent that it
tends to limit the degree of change to the API, might act as something
of a "governor" to the inevitable scope creep, and thereby keep things
more or less on schedule. Again, I wouldn't disagree, but I think there
are other ways to do that which still allow the big changes to happen.
The only down-side I can see is if no one wants to continue work on
Webwork 2.x.x. Then that community suffers.
Any thoughts?
Frank
Don Brown wrote:
Ok, let's just make this an official proposal and focus all of this
discussion:
I propose that the architecture plan for Struts Action 2.0 includes the
following:
1. A re-design of the API to simplify the framework the users see
2. Backwards-compatibility support for WebWork 2 and Struts 1.x
applications
3. Continue to use XWork for a) compatibility reasons and b) the core
implementation of the new API
4. A target GA release by August
This means for current WebWork 2 users:
1. WebWork continues to apply bug fixes for the WebWork 2.1.x and 2.2.x
branches
2. Migration to Struts Action 2.0 should take hours, not days, weeks,
but probably not minutes.
For Struts Action 1 users:
1. Struts Action 1.x will continue to be developed actively
2. Migration to Struts Action 2.0 should take days, using available
migration tools and compatibility libraries
I think this proposal is a good middle ground between folks that want
WebWork 2.2 with just package renaming, and others that want a
completely new framework.
Please register your comments and if necessary, I'll call a vote so we
can decide this once and for all, and get back to coding.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
