But to me, making sweeping changes to the core API should not be an option for a long time after 2.0 goes stable.
Sure, but why should 2.0 be seen as the "end of the road". Not so long ago, only early adopters used the #.0 version of anything, even if shrink-wrapped :) We already know 2.0 won't be the end of the rainbow. The plans for "phase 2" are much more aggressive than the "new API". In fact, "phase 2" is the place where we plan to embody "what everyone thinks of as the best of breed core API " * http://wiki.apache.org/struts/StrutsTi My thinking is strongly affected by the Struts 1.1 "death march". We had made some incremental changes, and some of us were about ready to roll a release. Then, there was a proposal to add "modules". It seemed clear-cut at first, but in the end, one change lead to another, and it was over a year before we had a release. (And another year of applying patches before "modules" were really stable.) In the meantime, a lot of other useful changes were kept out of the hands of teams that can only use a stable release. We spent a year telling people, "Oh that's fixed in the beta", only to find they can't use betas or nightly builds. I'm not saying that the new API will turn Struts 2.0 into a death march. But as Jason says, these are not internal changes. So, we will also need to update the documentation and the examples, which could expose other changes we need to make in the process. Meanwhile, we have redundant lines of development in Struts 2.0.x and WebWork 2.2.x. If we can stabalize Struts 2.0.x, and bring the rest of the WebWork community on board, we can go back to working together on a single codebase. Struts 1 may have a larger installed base than all other Java frameworks combined, but the WebWork user community is alive and kicking, and I would like their help too. If people want to make these changes now, then, fine, let's have at it. If not now, then when? -Ted. On 7/24/06, Tim Fennell <[EMAIL PROTECTED]> 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]
