These are all good points, and I'm happy to see the diverse involvement. I'm
wondering if perhaps we should reclassify the 2.0.0 release. To some, it
signifies the next great foundation to build web apps upon, and by doing so,
sweeps clean the legacies of Struts and WebWork. When I look at the 2.0.0 code,
to be honest, I don't see that...yet.
Here is how I would classify our roadmap:
Struts 2.0.x - WebWork transitional releases
Struts 2.1.x/3.0.x - The true successor to Struts and WebWork
I lay it out as I do for several reasons:
1. We need a stable release of Struts 2 out ASAP. Frequently releases are the
lifeblood for an open source project, both for its users and its developer
community.
2. The first Struts 2 release should be a trivial migration for WebWork users.
I think it is important to unite the two communities now, while the iron is hot.
Maintaining two source trees is problematic and, IMO, wastes precious
developer time.
3. Quite frankly, I don't see the Struts 2 source as of the quality I would
expect for the successor to WebWork 2. When I envisioned Struts Ti, I saw a
new, simplified development model that introduced new, backwards-incompatible
changes. In my mind, a true successor release would have:
- Zero configuration through judicious use of conventions and annotations
- Minimalistic framework API
- Built-in, hidden IoC framework to better wire the internals of Struts
- Comprehensive Ajax/Javascript support
Are all these things in the works or at least technically achievable in the next
few months? Sure, but to cleanly fold these capabilities into a cohesive
framework, iron out all the bugs, and develop the appropriate transition code
and documentation, I think would take at least a year to do it right.
The bottom line is we talk about stable releases as if we could whip them out
every few months with massive changes. I think it is more realistic to work on
a conservative stable release, while building the big features in a development
branch. Trying to insist the project should wait for all the big features we
desire would result in a framework that never is released. There is just a lot
more work that goes into a release than its code, unfortunately.
In summary, I agree with Ted's plan that if you can get in a working
implementation of big features like the new API by the end of July, they could
be included in the transition release, as long as the WebWork 2.2.x transition
is still possible. From my last talk with Bob, this is a possibility for the
new API.
Don
Tim Fennell wrote:
It's a gentle slide for WebWork 2.2 developers now, and some of us
would like to keep it that way.
Forever? Or just for the Struts 2.0 release? Because if you guys are
talking about making sweeping changes some time ... can you keep doing
this?
Now, if the current 2.0.0 doesn't represent your ultimate vision for
how the core of the framework should be and/or the APIs to
application land,
I like Google's slogan: The best is never good enough.
I don't think any framework we have today meets our ultimate vision
yet. If we continue to pursue perfection without releasing, we will
never achieve perfection.
I think perhaps I wasn't clear enough. I wouldn't expect Struts to
reach perfection then release and halt development ;) But I do think
that there's a core to WW/Struts that represents the essential parts of
the framework, and changes in APIs in this area significantly impact
application developers.
What I'd like to see is that 2.0 embodies what everyone thinks of as the
best of breed core API that should only change incrementally in the
future. If you want to completely re-write the core but stick to the
API after 2.0, fine! If you want to rewrite or change APIs to non-core
(value add) stuff after 2.0, fine! But to me, making sweeping changes
to the core API should not be an option for a long time after 2.0 goes
stable.
Most of the best suggestions in Struts 1, and I ventrue WebWork 1 and
2, have come from people outside of the core development community.
The longer we keep the codebase "under wraps", the longer it will be
until we have input from other working developers.
We need to face that fact that our in-basket will never be empty, and
we will always be making large changes in the next great API.
In fact, I believe, the best way to make the next API great, is to get
the API we have out there, so we can enjoy the feedback of our peers.
Sure, I won't dispute that. But that doesn't require that you push out
a stable/production release does it? As Jason suggested the Spring 2.0
milestones have had that effect while still making it clear that it's an
evolving product and liable to change. That said, I think the API
changes being suggested are perhaps more impactful that what's going on
inter-milestone with Spring (though since I've followed neither closely
I'm happy to be corrected).
-t
---------------------------------------------------------------------
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]
