Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <786fde50905202034n5250bc9dk844c39a7d734668c@mail.gmail.com>
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>
Date: Thu, 21 May 2009 07:17:29 -0400
Message-ID: <9ac0c6aa0905210417t8b06085j54dd207ac86e76b8@mail.gmail.com>
Subject: Re: Lucene's default settings & back compatibility
From: Michael McCandless <lucene@mikemccandless.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

OK so it sounds like we've boiled the proposal down to two concrete
changes to the back-compat policy:

  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.

  2) An API, once released as deprecated, is fair game to be removed
     in the next minor release.

We still only make bug fixes on point releases, support the index file
format until the next major release -- those don't change.

Mike

On Wed, May 20, 2009 at 11:34 PM, Shai Erera <serera@gmail.com> wrote:
>> With the new way, you can get the first bug fix release, but then you wi=
ll
>> quickly be left out of new bug fixes until you update your code.
>
> Mark, apologies for the late reference, but it struck me only after I lef=
t
> the computer yesterday. Again, I'm not sure how bit of a problem is it.
> Suppose that I upgrade to 2.4 and the next version (6 months?) is 2.9. Th=
en
> a bug is discovered and is fixed in 2.4.1 and 2.9. In addition, 2.9 conta=
ins
> all these changes in Collectors. When 2.9 is out I decide not to upgrade =
to
> 2.9 because I don't have time. When 3.0 comes out (3-4 months later?) I w=
ill
> be forced to upgrade. That means ~1 year since I last upgraded my Lucene
> code sections.
> (True, if there will be any bug fixes in 2.9, I will miss them).
>
> How unreasonable is to ask this? Seriously, how many apps are not touched
> *at all* during one year? And even if these code segments are stable and =
no
> one touches them anymore, how problematic is it to request users to once =
a
> year do a sort of cleanup and update to their code?
>
>> In other words, we keep deprecated around for only one or two versions.
>
> That is a reasonable approach. Meaning, defaults may change between relea=
ses
> because we'd like Lucene users to get the latest & greatest stuff, (and a=
lso
> count on the fact not so many out there strongly rely on the defaults?) b=
ut
> methods removal/rename should cause a little more trouble, so we can give
> the users one release to arrange their time before they have to do anythi=
ng.
>
> Maybe the TokenStream API needs to stay deprecated for longer, until we'r=
e
> sure everybody is happy with the new API.
>
> Shai
>
> On Thu, May 21, 2009 at 4:23 AM, Grant Ingersoll <gsingers@apache.org>
> wrote:
>>
>> On May 20, 2009, at 4:06 PM, Michael McCandless 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?
>>>
>>> Back-compat is insanely costly, especially the longer it takes us to
>>> get to the next major release... =A0yet, the specific cost that bothers
>>> me the most is that we hurt our new users because of the back-compat
>>> users. =A0It hurts Lucene's adoption/growth.
>>>
>>> Another consideration on relaxing policy is that back-compat is well
>>> nigh impossible to actually achieve. =A0We spend an insane amount of ou=
r
>>> 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. =A0It's not much bang and alot of buck.
>>>
>>> It is tempting to change our policy to something like:
>>>
>>> =A0* Bug fixes only on each 2.4.X release
>>>
>>> =A0* Anything can change on each 2.X release, but any prior 2.Y index
>>> =A0 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.".
>>
>>
>> All reasonable, Mike. =A0My take is that Lucene has always been pragmati=
c
>> about darn near everything, except back compat, where we are pretty
>> dogmatic.
>>
>> In general, I think it is reasonable to say that even from 2.x to 2.y we
>> will try to be back compatible, but when we deem it necessary, we reserv=
e
>> the right to change things. =A0I don't think anyone here is suggesting w=
e
>> would ever do something drastic like a complete overhaul of all the APIs=
 in
>> a version change. =A0I also think it is reasonable to deprecate things b=
y
>> saying @deprecated Will be removed in 2.Y. =A0Use coolNewMethod instead.=
 =A0 In
>> other words, we keep deprecated around for only one or two versions. =A0=
Of
>> course, the timing can vary. =A0Things like changing the Document stuff =
like
>> we've talked about might last longer (or shorter, actually) while minor
>> deprecations may only be kept for one. =A0The index compatibility stuff =
is a
>> must.
>>
>> It is probably worthwhile to ask on java-user@ how many people rely on o=
ur
>> back compat policies.
>>
>> <tongue in cheek> Of course, we do already support back compat for all
>> versions: =A0svn checkout
>> http://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_3_1/ =A0</tong=
ue in
>> cheek>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>

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