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]

Reply via email to