lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: Lucene's default settings & back compatibility
Date Thu, 21 May 2009 01:23:11 GMT

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:

View raw message