On Wed, May 20, 2009 at 3:24 PM, Shai Erera <ser...@gmail.com> wrote:
> Then why go through all this trouble and not simply change the back-compat
> policy?
OK so let's talk policy now ;)
We need some serious relaxing of the back-compat policy to make the
actsAsVersion proposal pointless.
Ie whenever we want to change a default, eg sorting by field should
not compute scores, IndexWriter should suddenly default autoCommit to
false, IndexReader.open gives you a readOnly reader, MultiTermQuery is
constant score by default (once we fix BQ to do constant score), docs
are scored out-of-order by BQ, stop filter preserves positions, etc.,
we need to be "allowed" (by our policy) make such changes in the next
dot release.
I want new users on every dot-release to always get the
latest&greatest defaults. Every change we make needs to be free to
adopt the best defaults.
If we relax our policy enough so that we have full freedom to set
defaults only according to new users, then I agree actsAsVersion is
not needed.
Back-compat is insanely costly, especially the longer it takes us to
get to the next major release... yet, the specific cost that bothers
me the most is that we hurt our new users because of the back-compat
users. It hurts Lucene's adoption/growth.
Another consideration on relaxing policy is that back-compat is well
nigh impossible to actually achieve. We spend an insane amount of our
energy maintaining back-compat, but then one accidental breakage that
slips through quickly causes many back-compat users to conclude we are
not back-compat. It's not much bang and alot of buck.
It is tempting to change our policy to something like:
* Bug fixes only on each 2.4.X release
* Anything can change on each 2.X release, but any prior 2.Y index
format is readable
I think it's not unreasonable to say "if you want to take advantage of
Lucene's perf improvements and new features, on upgrading you'll have
to recompile, fix APIs, etc.".
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
