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 15:29:30 GMT
OK it sounds like a single global actsAsVersion is too problematic.

So how about, for cases where back compat default settings are
important (analyzers, query scoring changes, etc.) we add
actsAsVersion as a mandatory ctor argument to those classes
(deprecating the other ctors)?  We would do this on demand, the first
time a class needs to change its default behavior.

For example, in 2.9 we'd like sorting by field to not return score by
default.  So, we'd add actsAsVersion to IndexSearcher's ctors, and
IndexSearcher then looks at the version it should emulate and sets the
defaults correctly.

New users would not use the deprecated API, and would pass
Versions.LUCENE_LATEST.  Existing users on upgrading would see that
they need to explicitly set their compatibility level (and, we'd default
it to the last version so that back-compat users don't see anything
break on upgrading).


On Fri, May 22, 2009 at 9:45 AM, Grant Ingersoll <> wrote:
> Perhaps it is wise to take a step back before we play all of these "what if"
> games...
> I think the best way forward is to simply ask ourselves, when confronted
> with an actual issue, is what is the cost of back compat. for this issue and
> then address it on a case by case basis, with a bias towards maintaining
> back compat if it is not too burdensome.  Too burdensome is a judgment call
> for the contributors and committers.
> As for the Settings vs. static actAs stuff, I really am on the fence.  They
> both have their downsides, so I'm inclined to punt.  Frankly, I think if
> someone wants 2.4.1 functionality and we're on 2.9 or even 3.0, but some of
> the new features available on 2.9, then they should backport the patches.  I
> don't think the burden should be on us to have the trunk support every
> single setting that was ever available on a given 2.x release given the time
> frames we operate on  The fact is, we are obsessing over the name of the
> release, when the more important factor is the time it takes to make the
> release.  If we released once a month, I'd be inclined otherwise, but for
> the reality we are in, I'm almost ready we to say we should just chuck the
> whole major minor thing and say we go the MS way:  Lucene 2009 and then have
> service pack releases for just that year's major release (I realize, of
> course, they likely have internal versions, etc. but maybe not)
> -Grant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message