As soon as webwork 2.2.3 is out I will concentrate my help on Struts 2.0. I want to help in getting the new API implemented ASAP.
Rainer > I like it. If we can get a functioning implementation of the API in by > Monday, > it goes in 2.0.x. Bob, please commit anything you have, as I'd like to > help in > getting the API in there. > > Don > > Ted Husted wrote: >> I would like to propose a versioning roadmap for Struts 2 and beyond. >> >> * 2.0.x series == WebWork transitionary release >> >> * 2.1.x series = "New API" release >> >> * 3.x series = "Best of breed/Phase 2" release >> >> The proposal extends the original Ti proposal by adding a 2.1 series >> to accomodate the API changes suggested in the Rough Spots page. >> >> The new API could be implemented in the 2.0.x series, if someone is >> interested in doing the work, and the existing API supported in a >> deprecated fashion. Then, the 2.1 series would be when we remove >> support for the "old" API. Other changes that would break with the >> WebWork 2.2 API could also be scheduled for the 2.1 series (such as >> removing the WebWork compatibility switch). >> >> But, if no one is interested in working on the new API now, it should >> not be framed as an impediment to a stable Struts 2.0 release. We >> should judge each distribution on terms of what we have done, not on >> what we would like to do. >> >> -Ted. >> >> >> On 7/24/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: >>> On 7/24/06, Ted Husted <[EMAIL PROTECTED]> wrote: >>> > >>> > -1 on changing the versioning scheme. >>> > >>> > But, I would be open to something like >>> > >>> > * Struts 2.0 == "WebWork transtional release" >>> > * Struts 2.1 == "new API release" >>> > * Struts 3.x == "phase 2 - the best of breed release" >>> >>> ...with pointers on what to consider if users should upgrade or not, >>> and a clear explanation of what to expect in the near future. This >>> could address Tim's initial concern (which I think is valid): >>> >>> "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." >>> >>> Those three lines above, listing 2.0, 2.1 and 3.x, could be >>> communicated on the front page, on a simple table. This would be >>> similar to how Tomcat explains why they have three versions. Very >>> straightforward and easy to digest. >>> >>> Hubert >>> >>> >>> > IMHO, all the users, including ourselves, are served best when we >>> > release early and release often. >>> > >>> > -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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
