lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yonik Seeley <>
Subject Re: Lucene's default settings & back compatibility
Date Fri, 22 May 2009 16:44:56 GMT
I'm not a lawyer, so I dislike trying to nail down every detail in
writing and try to solve future problems in the abstract.

Lucene has never really been 100% back compatible... we've just tried
to keep it that way... it's more of a mindset than a reality, and I'm
wary of changing that mindset too much.  Lucene has benefited from API
and design stability, and I think the bar should be kept high for
changes (i.e. there should be clear benefits).

Anyway, I think substantially relaxing back compat requirements is
enough of a change that it should at some point go to a vote (once
people figure out exactly what is being voted on ;-)
That doesn't apply to a static actsAsVersion that would preserve back
compatibility by default of course.

>  3. Default settings can change, but if the change is big enough (and
>     certainly if it will impact what's indexed or how searches find
>     docs/do scoring), we add a required "actsAsVersion" arg to the
>     ctor of the affected class.  New users get the latest & greatest,
>     and upgraded users keep their old defaults.

If we get to the point of passing something around, it might as well
be a Settings object, unless it's an inner loop efficiency thing.
Depending on the specifics, it may often be simpler/cleaner to create
a new class / constructor and deprecate the old, as we do now.

>  4. [Maybe?] Allow certain limited changes that will require source
>     code changes in your app on upgrading to a new minor release:
>     adding a new method to an interface, adding a new abstract method
>     to an abstract class, renaming of deprecated methods.

+1, depending on the specifics.  This is where back compat rules
shouldn't be cast in stone.
There are some public classes in Lucene that are really just
implementation artifacts - pretty much no one will directly use those
classes and changes to those shouldn't be a big deal.


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

View raw message