lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
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.

Mike

On Fri, May 22, 2009 at 2:20 PM, DM Smith <dmsmith555@gmail.com> wrote:
> Michael McCandless wrote:
>>
>> On Fri, May 22, 2009 at 12:52 PM, Marvin Humphrey
>> <marvin@rectangular.com> 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: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message