I'm still +1 on calling this 3.0 as I was before when you mentioned it. Its a wakeup call that the upgrade is a bit major in certain areas.
In either case - 3.0 is more representative of what this release is IMO. I also think we should allow new features in 3.0 if we release this as 2.9. - Mark Michael McCandless wrote: > Right, this (you can jump to 2.9, fix all deprecations, then easily > move to 3.0 and see no deprecations) is my understanding too, but I > don't see what's particularly useful about that. It does produce a > Lucene release that has zero deprecated APIs (assuming we remove all > of them), but I don't think that's very important. Also, it's extra work > having to do a "no-op, except for deprecations removal and generics > addition" release :) > > Vs say taking our time creating 3.0, letting it have real features, > etc. > > Or, another option would be to simply release 3.0 next. After all, > there are some seriously major changes in this release, compilation > breakage, etc. ... things you'd more expect (of "traditional" > software) in a .0 release. And, then state clearly that all > deprecated APIs in 3.0 will be removed in 3.1. While this is > technically a change to our back-compat policy, it's also just a > number-shifting game since it would just be a rename > (2.9 becomes 3.0; 3.0 becomes 3.1). > > Mike > > On Thu, Aug 20, 2009 at 8:58 AM, Mark Miller<markrmil...@gmail.com> wrote: > >> Michael McCandless wrote: >> >>> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<markrmil...@gmail.com> wrote: >>> >>> >>> >>>> I forgot about this oddity. Its so weird. Its like we are doing two >>>> releases on top of each other - it just seems confusing. >>>> >>>> >>> I'm also not wed to the "fast turnaround" (remove deprecations, switch >>> to generics) 3.0 release. >>> >>> We could, instead, take out time doing the 3.0 release, ie let it >>> include new features too. >>> >>> I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround, >>> but I can't remember it nor find it now... >>> >>> Mike >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: java-dev-h...@lucene.apache.org >>> >>> >>> >> I thought the motivation was to provide a clean upgrade path with the >> deprecations - you move to 2.9 and move from all the deprecated methods >> - then you move to 3.0 and your good with no deprecations. I'd guess the >> worry is that new features in 3.0 would add new deprecations and its not >> quite so clean? >> >> Personally, I think thats fine though. New deprecations will come in 3.1 >> anyway. You can still move everything in 2.9, and then move to 3.0 - so >> what if something else is now deprecated? You can move again or wait for >> 3.9 to move ... >> >> -- >> - Mark >> >> http://www.lucidimagination.com >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- - Mark http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
