On Mon, 2006-07-24 at 16:35 -0400, 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).
I was looking in DefaultActionMapper and am wondering about the compatibilityMode switch functionality. In getMapping compatibilityMode is used to see whether to check for the ! method idiom. I assume this is because it will eventually be removed because wildcard mappings make it redundant. But in the constructor, the PrefixTrie that's being set up is also checking the compatibilityMode switch to see if it should add a node for the "method:" prefix. Should that be there? Is there someway in which you can use wildcards in your mapping in order to replace the parameter prefix? So that the button the user clicks will determine which method is run? dave > 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]
