lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Lucene's default settings & back compatibility
Date Fri, 22 May 2009 18:49:01 GMT
OK, net/net it doesn't look like we're going reach agreement on some
general approach for having users of Lucene always get the best
default settings.

We started with the *Settings classes, but that's really a very large
project (goes far beyond managing defaults for new users).

Then we went to the other end of the spectrum with a single global
actsAsVersion, but sneaky spooky action at a distance bugs nixed that.

We thought about storing actsAsVersion in the index, but that's too
automagic (and would also lead to sneaky bugs / confusion).

Finally we considered about passing in actsAsVersion to those classes
that need to change their defaults, but people would prefer Settings
over this.

Unless there are other ideas out there, I think at this point we
should just fallback to the "make a new method making the setting
explicit, and deprecate the old one" approach.  It achieves the goal,
on a case by case basis, without changing our back-compat policy nor
adding any new Settings/actsAsVersion infrastructure to Lucene.


On Fri, May 22, 2009 at 2:20 PM, DM Smith <> wrote:
> Michael McCandless wrote:
>> On Fri, May 22, 2009 at 12:52 PM, Marvin Humphrey
>> <> wrote:
>>>> when working on 3.1 if we make some great improvement, I'd like new
>>>> users in
>>>> 3.1 to see the improvement by default.
>>> Sounds like an argument for more frequent major releases.
>> Yeah.  Or "rebranding" what we now call minor as major releases, by
>> changing our policy ;) Or "rebranding" to Lucene 2009.
>> But: localized improvements (like the sizable performance gain from
>> turning off scoring when sorting by field) should not have to wait for
>> a major release to benefit new users.  I think they should be on by
>> default on the next release.
> This proposed policy change of allowing backward compatibility in the API to
> change within a major release is nothing more than smoke and mirrors. But I
> see two side effects:
> 1) Debian, Fedora, and perhaps other Linux distributions, see minor releases
> as maintaining backward compatibility. With Debian, they bump their major
> revision number with each break in backward compatibility. I didn't check,
> but my guess is that the version name of Lucene in Debian corresponds with
> that of Lucene itself. I'd hate for that to change. How would you like to
> see Debian to name it Lucene 4 or Lucene 5, when we are doing Lucene 3.x. It
> gets confusing. (Real example:  libsword7, which corresponds to the 1.5.11
> release of SWORD and libsword8 corresponds to 1.6.0.)
> 2) Backward compatibility of the index is at least 2 major revisions and
> that is not proposed to change. Now with this, we effectively postpone it
> indefinitely. Rather than the index being allowed to change when the API has
> broken compatibility at most 2 times, with this proposed change, we can
> break API compatibility a dozen times. At the future point where this policy
> is brought into question, with something like "Now that we can break
> backward compatibility in the API frequently, we need to change our policy
> for the index to match", then we will have come full circle.
> At first, I liked the idea a lot, but now less so. Now I'm leaning toward
> changing major revision number when backward compatibility changes and for
> more frequent major releases if that is what it takes.
> This was the thrust of my tongue-in-cheek proposal of weekly minor and
> monthly major releases.
> I also share Marvin's and others' concerns about sneaky bugs introduced by
> globals. In my situation, Lucene is part of a desktop application and the
> user can create hundreds of indexes and use them within the application.
> With a *.deb or *.rpm, we'll have to specify that they cannot use anything
> but the minor release for which the application was designed. Before, we
> could say that one could drop in anything of the same major release number.
> I don't think I am alone or unique in embedding Lucene into a desktop
> application. I know it is a part of Eclipse (at least on Fedora).
> This change might have the opposite effect of making people's perception of
> Lucene as one of instability. Guard carefully against that, please!
> -- DM
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message