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]