Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of serera@gmail.com designates
 209.85.219.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=qeaIb8NpXZdLRXxOA/mTfha+ZW5DsTlnmxFGLvmOFZg4KQ7ACRMa5XjltnUJyI0h23
         azp3cutfBxT+HBZsbOZ/f9UJfX9heKQQVTXnQ3OuMp7jcpV8Ultp5pt8BCi9BqhYVnMd
         yOuE3iQmtkDArb4NCCQDVgOTiZqxaoQZqUQiI=
MIME-Version: 1.0
In-Reply-To: <9ac0c6aa0905201306p7948fae0sfe57e3a70eebe137@mail.gmail.com>
References: <9ac0c6aa0905181406l5c951016k97a16d8db766716e@mail.gmail.com>
	 <59b3eb370905200657v7ce32a68uf70428c4f7f7e051@mail.gmail.com>
	 <20090520150613.GA4351@rectangular.com> <4A1425BF.2050607@gmail.com>
	 <c68e39170905200857u154418afsf7cb43d7f147c36@mail.gmail.com>
	 <9ac0c6aa0905200914t142dfd59hef160d26e879d989@mail.gmail.com>
	 <alpine.OSX.2.00.0905200933140.71522@yuzu.local>
	 <9ac0c6aa0905201210l2becda41ic5d51b22fca043e@mail.gmail.com>
	 <786fde50905201224i56c6184et463254a8aeb83949@mail.gmail.com>
	 <9ac0c6aa0905201306p7948fae0sfe57e3a70eebe137@mail.gmail.com>
Date: Wed, 20 May 2009 23:17:40 +0300
Message-ID: <786fde50905201317j4cbd11acq5586138dba06fc7f@mail.gmail.com>
Subject: Re: Lucene's default settings & back compatibility
From: Shai Erera <serera@gmail.com>
To: java-dev@lucene.apache.org
Content-Type: multipart/alternative; boundary=0016364c7b8d28da2b046a5db821

--0016364c7b8d28da2b046a5db821
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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 <
lucene@mikemccandless.com> wrote:

> On Wed, May 20, 2009 at 3:24 PM, Shai Erera <serera@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

--0016364c7b8d28da2b046a5db821
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Earwin - I wrote it before - index structure is the only b=
ack-compat policy I propose to keep, and not for just one major release, bu=
t for 2 (which I believe is the current behavior already). I also absolutel=
y don&#39;t want to give that up.<br>
<br><blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin:=
 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote">I think it=
9;s not unreasonable to say &quot;if you want to take advantage of<br>
Lucene&#39;s perf improvements and new features, on upgrading you&#39;ll ha=
ve<br>
to recompile, fix APIs, etc.&quot;.<br></blockquote><br>+1 (am I allowed to=
 cast +1s not being a committer?) :)<br><br><div class=3D"gmail_quote">On W=
ed, May 20, 2009 at 11:06 PM, Michael McCandless <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:lucene@mikemccandless.com">lucene@mikemccandless.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Wed, May 20, 2=
009 at 3:24 PM, Shai Erera &lt;<a href=3D"mailto:serera@gmail.com">serera@g=
mail.com</a>&gt; wrote:<br>

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

--0016364c7b8d28da2b046a5db821--