Earwin - I wrote it before - index structure is the only back-compat policy
I propose to keep, and not for just one major release, but for 2 (which I
believe is the current behavior already). I also absolutely don't want to
give that up.

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.".
>

+1 (am I allowed to cast +1s not being a committer?) :)

On Wed, May 20, 2009 at 11:06 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> 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
>
>

Reply via email to