If the WebWork committers make the decision to continue developing WebWork 2.x,
they are entirely free to do so. If Struts Action 1 committers decide to
continue developing Action 1, they are also free to do so. However, if WebWork
2 developers decide to stop work and focus completely on Struts Action Framework
2, that is also their decision.
The purpose of this merger is not to create yet another framework or kill off
competition, but to start collaborating as framework developers for the greater
good of the general community. By focusing on who can do what or why can't a
project release something, you are missing the point. The point is to
collaborate to build a single Action-based framework that combines the talents
of the Struts and WebWork teams, and hopefully more. Yes, there will be
compromises, and yes, we can't "force" anyone to do anything, but we are here
aren't we, so let's make the most of it.
The purpose of this proposal is come to some sort of agreement of where we want
to take Struts Action 2, so we can get back to work.
Don
Frank W. Zammetti wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
