lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven A Rowe <>
Subject RE: Lucene's default settings & back compatibility
Date Thu, 21 May 2009 22:38:32 GMT
On 5/21/2009 at 7:17 AM, Michael McCandless wrote:
> OK so it sounds like we've boiled the proposal down to two concrete
> changes to the back-compat policy:
>   1) Default settings can change; we will always choose defaults
>      based on "latest & greatest for new users".  This only
>      affects "runtime behavior".  EG in 2.9, when sorting by
>      field you won't get scores by default.  When we do this we
>      should clearly document the change, and what settings one
>      could use to get back to the old behavior, in CHANGES.txt.
>   2) An API, once released as deprecated, is fair game to be
>      removed in the next minor release.
> We still only make bug fixes on point releases, support the index
> file format until the next major release -- those don't change.

Contrasting the upgrade experience of existing "maintenance" users (i.e., users not using
new Lucene features) under current policy with their experience under the above proposals:

Currently there are two upgrade experiences for these users: a) upgrading within the same
major release; and b) major release upgrades.  

For a), the user reads CHANGES for back-compat exceptions, but otherwise has drop-in compatibility.
 For b), the user performs two upgrades: first, just like in a), to the last minor release
in the same major release, addressing all deprecation warnings; and second, to the major release,
with drop-in compatibility, modulo CHANGES.

Here's the upgrade procedure under the above proposals, from version X.Y to X.Z:

1. Address all deprecation warnings against the currently used Lucene version (call it version

2. Upgrade to X.(++Y), addressing all deprecation warnings and checking CHANGES for exceptions
to the back-compat policy, including mechanisms to maintain X.Y[0] defaults. 

3. Iterate #2 until Y==Z.

One consequence of these changes is that major version upgrades the same as minor version
upgrades, with the exception that index format support (and default settings support?) will
potentially require attention.

Another consequence is that upgrade effort will no longer be amortizable.  Currently, maintenance
users can skip minor version upgrades with almost no penalty, and defer the upgrade pain to
major release upgrades, since deprecation warnings can be safely ignored.  (Not advocating
this practice, just noting that it's possible.)


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

View raw message