On Tue, May 19, 2009 at 4:50 PM, Yonik Seeley
<yo...@lucidimagination.com> 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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
