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 Fri, 22 May 2009 16:25:34 GMT
>  1. If we deprecate an API in the 2.1 release, we can remove it in
>     the next minor release (2.2).
Agree. Maybe also this?
1a. If deprecated functionality is trivially implemented with new one,
we reserve the right to delete deprecated things right away with
appropriate CHANGES note.
Sample I:
getOmitTF() is deprecated in favor of
getOmitTermFrequenciesAndPositions() which is absolutely identical to
the former, save for the name
getOmitTF is removed, CHANGES.txt contains a line telling the user to
do search/replace on his code

Sample II:
score(HitCollector, int) is deprecated in favor of score(Collector, int)
score(HitCollector, int) is removed, CHANGES.txt contains a line
telling the used to wrap his collector with new HitCollectorWrapper()
or reimplement

>  2. JAR drop-in-ability is only guaranteed on point releases (2.4.1
>     is a drop-in replacement to 2.4.0).  When switching to a new
>     minor release (2.1 -> 2.2) likely you'll need to recompile.

>  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.
What about a default value for actsAs? I mean, if I agree with using
Version.LATEST_AND_GREATEST, why do I have to explicitly set it every

>  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.
Yahoo! The right to rename deprecated things makes the need to
deprecate VS simply remove bearable.

One more thing. What about adopting fixed release schedule?
I.e. minor releases are done strictly each three/four/six months.
Whatever is finished - goes into release, whatever is not - continues
rotting as patches in jira.
Either this, or my addition to rule #1 has to be made, or we're going
to wait for two years before removing something. First year until a
minor release that declares deprecation, another year until next minor
release that actually removes garbage.

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