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