The generally accepted terminology for release numbering is MAJOR.MINOR.PATCH. Yes, Struts does things strangely, but that doesn't change how users expect things to work. Throwing in big features, and yes, I consider new annotations big features as they worm their way into user code, is not something I feel comfortable doing in a "third-level" release, or whatever we call it.
In this case, the annotations will be likely redone for 2.1 anyways. A lot of it is my fault - they have been kinda thrown in there without systematic thought, and I had hoped we could fix that for 2.1. I'd hate to introduce new annotations only to deprecate them weeks later. Don On 9/21/07, Ted Husted <[EMAIL PROTECTED]> wrote: > As I understand it, 2.0.x is not a "patch release". It's part of the > 2.0.x minor release series. By our reckoning, 2.0.10.1 would be a > "patch" release, and in that case, I would agree. > > AFAIK, we have always agreed that minor releases are *not* > feature-locked. If we start feature-locking minor-releases, IMHO, we > will *never* get a timely GA vote on a minor release, because everyone > will say "wait, wait, one more thing". (Been there, did that, burned > the T-shirt!) > > We do have annotations in the 2.0.x series, but we are missing > ActionName/ActionNames annotations. We would simply be finishing what > we already started. No one is suggesting that we change any existing > behavior, but that we simply add in the ActionName.ActionNames > annotations in the same way that we have ResultName and ResultNames > annotations. > > -Ted. > > On 9/20/07, Don Brown <[EMAIL PROTECTED]> wrote: > > I'd prefer we give this more thought and keep it in the 2.1.x branch. > > I view patch releases as those that only provide bug fixes or minor > > stability features. Something like annotations, which will be used in > > client code, is really a public API feature and should be reserved for > > minor, at the least, feature releases. > > > > Don > > > > On 9/18/07, Ted Husted <[EMAIL PROTECTED]> wrote: > > > I was just wondering if it would make any sense to at least add > > > SmartURL-type ActionName and ActionNames annotations to the 2.0.x > > > core, so as to finish what we started with the validation and result > > > annotations. We probably don't need to get into exception and > > > interceptor annotations for 2.0, but ActionNames would be nice. > > > > > > -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]