lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Lucene's default settings & back compatibility
Date Thu, 21 May 2009 11:17:29 GMT
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.


On Wed, May 20, 2009 at 11:34 PM, Shai Erera <> wrote:
>> With the new way, you can get the first bug fix release, but then you will
>> 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 left
> 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. Then
> a bug is discovered and is fixed in 2.4.1 and 2.9. In addition, 2.9 contains
> 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 will
> 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 releases
> because we'd like Lucene users to get the latest & greatest stuff, (and also
> count on the fact not so many out there strongly rely on the defaults?) but
> 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 anything.
> Maybe the TokenStream API needs to stay deprecated for longer, until we're
> sure everybody is happy with the new API.
> Shai
> On Thu, May 21, 2009 at 4:23 AM, Grant Ingersoll <>
> wrote:
>> On May 20, 2009, at 4:06 PM, Michael McCandless wrote:
>>> On Wed, May 20, 2009 at 3:24 PM, Shai Erera <> 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...  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.".
>> All reasonable, Mike.  My take is that Lucene has always been pragmatic
>> 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 reserve
>> the right to change things.  I don't think anyone here is suggesting we
>> would ever do something drastic like a complete overhaul of all the APIs in
>> a version change.  I also think it is reasonable to deprecate things by
>> saying @deprecated Will be removed in 2.Y.  Use coolNewMethod instead.   In
>> other words, we keep deprecated around for only one or two versions.  Of
>> course, the timing can vary.  Things 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.  The index compatibility stuff is a
>> must.
>> It is probably worthwhile to ask on java-user@ how many people rely on our
>> back compat policies.
>> <tongue in cheek> Of course, we do already support back compat for all
>> versions:  svn checkout
>>  </tongue in
>> cheek>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message