struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <>
Subject Re: [s2] Struts 2.0.0 - Tag it and Roll it?
Date Mon, 24 Jul 2006 19:31:38 GMT
> 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 "


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?


On 7/24/06, 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:
For additional commands, e-mail:

View raw message