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 Wed, 20 May 2009 11:22:14 GMT
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.


  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

So net/net I'm +1!


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

View raw message