struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Fennell <>
Subject Re: [s2] Struts 2.0.0 - Tag it and Roll it?
Date Mon, 24 Jul 2006 17:38:28 GMT
I don't often reply to messages on these lists, but I feel like I  
have to offer a (relatively) outside perspective here.

There's been a lot of confusion external to apache about what's going  
on with Struts.  With Shale moving to a TLP, that's helped, but I  
think a lot of people are still confused about exactly what Struts  
2.0 will be.

If I've read this list correctly then it is already at a place where  
it is not a straightforward upgrade for either Struts of WW users  
(perhaps I'm wrong, but that's my current perspective).  Which means  
that if it's released as a stable release, people will try to adopt  
it, and expend serious effort moving to it.

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, then I /personally/ think that it would be  
irresponsible to move towards a /stable/ release just because of the  
original August timeframe that was picked months ago.  Users who  
don't keep completely up to date with the latest goings on will see  
this as the latest and greatest and start migrating to it, only to  
have a very rude surprise when large changes occur in 2.1, or a 3.0  
arrives months later.  Would it not be worth postponing the push  
towards a stable release in order to make the core and API as solid  
and permanent a base as possible?

Of course, I could be wrong and you could be discussing large changes  
that are largely backwards compatible.  If that's the case, then my  


On Jul 24, 2006, at 1:22 PM, Ted Husted wrote:

> It's not about the numbering system; it's about the August people like
> to bandy about.
> Realistically, if we are going to have anything like a stable release
> in the August timeframe, we need to feature lock now, so that we can
> test and document what we already got.
> I'm not against the new API, and I'm not against making "large
> changes". I'm against waiting any longer before we decide whether we
> are going to make the changes or not.
> If people are not quite ready to roll out the new API, I'd also be
> very open to starting on the 2.1.x series as soon as we have a
> reasonable 2.0.x distribution.
> The hard, realistic question is whether people are ready to do the
> work now or six weeks from now.
> -Ted.
> On 7/24/06, Don Brown <> wrote:
>> Now wait a minute - what happened to our alpha releases?  In a  
>> more traditional
>> scheme, you would have "2.0 alpha" and "2.0 alpha 1", which could  
>> contain
>> basically anything you want.  The clear alpha designation  
>> indicates that big
>> changes are in progress and this is more of a milestone release to  
>> encourage
>> development contributions.
>> As we are going with this Tomcat/HTTPD-style system, I was under  
>> the impression
>> that "2.0 alpha" would become "2.0.0 quality alpha" and could  
>> still contain
>> anything we want.  Therefore, 2.0.0 and 2.0.1 could have radically  
>> different
>> content because both were judged alpha quality.
>> Either we allow anything we want, including a new api, in the  
>> 2.0.x releases
>> until a beta is declared, or we should move back to a more  
>> familiar release
>> naming system.  Development milestones are important and they  
>> shouldn't be
>> eliminated.
>> Don
>> Ted Husted wrote:
>> > On 7/23/06, Bob Lee <> wrote:
>> >> If we want to tag now, the new API will have to wait for 3.0.
>> >
>> > I think we are reaching the point where if we still want to make
>> > "large changes" for 2.0,  we need to make them now, or make them in
>> > 2.1. AFAIC, we can open 2.1 as soon as we have a stable 2.0
>> > distribution. (Or as soon as someone volunteers to port the  
>> patches.)
>> >
>> > But, with my release manager hat on, I am saying that any "large
>> > changes" slated for 2.0.x have to be committed by July 31, or be
>> > postponed.
>> >
>> > -Ted.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message