On 7/24/06, Tim Fennell <[EMAIL PROTECTED]> wrote:
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.
Shale graduating to top-level hasn't any affect on our plans for this codebase. All that's happened is that we were able to drop the "action" moniker, and Struts is just Struts again.
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).
It's a gentle slide for WebWork 2.2 developers now, and some of us would like to keep it that way.
Which means that if it's released as a stable release, people will try to adopt it, and expend serious effort moving to it.
WebWork teams perhaps, but Struts 1 teams are glacial when it comes to decisions like this. From my experience, the majority of Struts teams are still using Struts 1.1. If we bring out a stable release now, I would venture that the earliest most teams would consider upgrading is Q1 2007
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.
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?
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.
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]
-- HTH, Ted. * http://www.husted.com/struts/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
