lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: Lucene's default settings & back compatibility
Date Wed, 20 May 2009 12:00:11 GMT
Michael McCandless wrote:
> On Tue, May 19, 2009 at 4:50 PM, Yonik Seeley
> <> wrote:
>>> Right, that's exactly why I want to fix it (only one behavior allowed
>>> and so for all of 2.* we must match the 2.0 behavior).
>> I meant one jar per per-jvm gives you one behavior (as is the case now).
>> But by setting a static actsAs version number, you could get a 2.* jar
>> to behave as if it were 2.0, even as behaviors evolve.
> So I think you're suggesting something like this: when you use Lucene,
> if you want "latest and greatest" defaults, do nothing.
> If instead you want defaults to match a particular past minor release,
> you must call (say) LuceneVersions.setVersion(VERSION_21).
> Any place inside Lucene that has defaults that need to vary by version
> would then check this, and act accordingly.
> I absolutely love the simplicity of this solution (far simpler than
> *Settings classes).  It would achieve what I'm aiming for, which is to
> always be free on every minor release to set the defaults for new
> users to the latest & greatest.
> But:
>   1) It means any usage of Lucene inside the JRE must share that same
>      version default
>   2) It's a change to our back-compat policy, in that it requires the
>      app to declare what version compatibility it requires.
> On #1, maybe this is in fact just fine, since as you pointed out
> that's de-facto what we have today; it's just that the "actsAs" is
> hardwired to 2.0 for all 2.x releases.
> On #2, I think shifting the burden onto those apps that do in fact
> need strict back-compat on upgrading, to have to set the actsAs is a
> good change to our policy.  After all, we think such users are the
> minority and putting the burden on new users of Lucene seems
> unreasonable.
> So net/net I'm +1!
> Mike
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
I kind of like it too. I like the core proposal, but I am not a big fan 
of having to pass a settings class to each of the major Lucene classes. 
A single static call would be much preferable.

- Mark

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

View raw message