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
apologies...
-t
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
