On Sun, Aug 23, 2009 at 7:38 PM, Robert Muir<rcm...@gmail.com> wrote: > just wanted to mention this (i honestly don't have any opinion either way): > >> 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 :) > > But isn't it also true it could be a bit more than no-op: > 1) changing to "better" defaults in cases where back compat prevents > this. I think I remember a few of these? > 2) bugfixes found after release of 2.9 > 3) performance improvements, not just from #1 but also from removal of > back-compat shims (i.e. tokenstream reflection) > > I am not saying this stuff is really important to users to merit a > release, but I don't think it is a no-op either.
I agree with robert that this is very likely not to be a no-op release. Changing to 1.5 brings in generics and lots of other stuff which could bring improvements. All the concurrent improvements, VarArgs and Utils in classes like Integer (valueOf) etc. I believe that we find may places in the code where existing stuff could be improved with the ability to commit 1.5 code. Moving to 1.5 with 3.0 would be a clean step in my eyes. Having 3.0 with 1.4 back-compat and then 3.1 which get rid of this would confuse users. simon > > -- > Robert Muir > rcm...@gmail.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
