Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Steven A Rowe <sarowe@syr.edu>
To: "java-dev@lucene.apache.org" <java-dev@lucene.apache.org>
Date: Thu, 21 May 2009 18:38:32 -0400
Subject: RE: Lucene's default settings & back compatibility
Thread-Topic: Lucene's default settings & back compatibility
Thread-Index: AcnaBdLBnnEosK6LQHWgdh42IqY6hwAVI7Sg
Message-ID: 
 <2D127F11DC79714E9B6A43AC9458147F19A36CF9@suex07-mbx-03.ad.syr.edu>
References: <9ac0c6aa0905181406l5c951016k97a16d8db766716e@mail.gmail.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>
	 <D2502CE9-5B29-434B-8DBC-0540B5EF32C7@apache.org>
	 <786fde50905202034n5250bc9dk844c39a7d734668c@mail.gmail.com>
 <9ac0c6aa0905210417t8b06085j54dd207ac86e76b8@mail.gmail.com>
In-Reply-To: <9ac0c6aa0905210417t8b06085j54dd207ac86e76b8@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

On 5/21/2009 at 7:17 AM, Michael McCandless wrote:
> OK so it sounds like we've boiled the proposal down to two concrete
> changes to the back-compat policy:
>=20
>   1) Default settings can change; we will always choose defaults
>      based on "latest & greatest for new users".  This only
>      affects "runtime behavior".  EG in 2.9, when sorting by
>      field you won't get scores by default.  When we do this we
>      should clearly document the change, and what settings one
>      could use to get back to the old behavior, in CHANGES.txt.
>=20
>   2) An API, once released as deprecated, is fair game to be
>      removed in the next minor release.
>=20
> We still only make bug fixes on point releases, support the index
> file format until the next major release -- those don't change.

Contrasting the upgrade experience of existing "maintenance" users (i.e., u=
sers not using new Lucene features) under current policy with their experie=
nce under the above proposals:

Currently there are two upgrade experiences for these users: a) upgrading w=
ithin the same major release; and b) major release upgrades. =20

For a), the user reads CHANGES for back-compat exceptions, but otherwise ha=
s drop-in compatibility.  For b), the user performs two upgrades: first, ju=
st like in a), to the last minor release in the same major release, address=
ing all deprecation warnings; and second, to the major release, with drop-i=
n compatibility, modulo CHANGES.

Here's the upgrade procedure under the above proposals, from version X.Y to=
 X.Z:

1. Address all deprecation warnings against the currently used Lucene versi=
on (call it version X.Y[0]).

2. Upgrade to X.(++Y), addressing all deprecation warnings and checking CHA=
NGES for exceptions to the back-compat policy, including mechanisms to main=
tain X.Y[0] defaults.=20

3. Iterate #2 until Y=3D=3DZ.

One consequence of these changes is that major version upgrades the same as=
 minor version upgrades, with the exception that index format support (and =
default settings support?) will potentially require attention.

Another consequence is that upgrade effort will no longer be amortizable.  =
Currently, maintenance users can skip minor version upgrades with almost no=
 penalty, and defer the upgrade pain to major release upgrades, since depre=
cation warnings can be safely ignored.  (Not advocating this practice, just=
 noting that it's possible.)

Steve


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org