lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Willnauer <>
Subject Re: Finishing Lucene 2.9
Date Sun, 23 Aug 2009 18:06:33 GMT
On Sun, Aug 23, 2009 at 7:38 PM, Robert Muir<> 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

> --
> Robert Muir
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message