lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <>
Subject Re: Lucene's default settings & back compatibility
Date Wed, 20 May 2009 21:03:56 GMT
> That said, I see the points and value of relaxing the back compat policy as well. Its
been discussed a lot in the past, and it has been eased in the past.
Afraid to ask which additional shackles Lucene bore in the past. I
mean, 'what' has to be eased to produce policies we have right now?
Joking, just really happy that something is seemingly going to change.

> When the flood gates open, and code is rolling all over the place, upgrading Lucene becomes
less of a buffet and more of a pain in the a**
Really, I've got a major pain in the *s* upgrading from 2.4 to trunk
(2.9). I upgraded to get per-segment collection and had to rewrite my
nontrivial collectors - no back compat effort could save me from it.

So, where to cast my weightless vote? :)

> We still should balance the "cost" of non back-compatible changes with
> the benefits.  As Doug has said: "Lucene has a large install base.  A
> little effort towards back-compatibility on our part saves folks a lot
> of effort."
That's a good approach.
Renaming a method, changing/adding some constructor parameters is
really easy, you don't need to keep old things around.
Doing deletes/norm updates through IndexWriter instead of IndexReader
- that's more work, but it's not complex.
Going from old Analyzer API to new one, or HitCollector -> Collector,
that's where real pain starts, because API changed dramatically not
only in its form, but in its meaning too. So a back-compat layer there
is reasonable.

Kirill Zakharenko/Кирилл Захаренко (
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

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

View raw message