lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <dmsmith...@gmail.com>
Subject Re: Lucene's default settings & back compatibility
Date Fri, 22 May 2009 18:20:31 GMT
Michael McCandless wrote:
> On Fri, May 22, 2009 at 12:52 PM, Marvin Humphrey
> <marvin@rectangular.com> wrote:
>   
>>> when working on 3.1 if we make some great improvement, I'd like new users in
>>> 3.1 to see the improvement by default.
>>>       
>> Sounds like an argument for more frequent major releases.
>>     
>
> Yeah.  Or "rebranding" what we now call minor as major releases, by
> changing our policy ;) Or "rebranding" to Lucene 2009.
>
> But: localized improvements (like the sizable performance gain from
> turning off scoring when sorting by field) should not have to wait for
> a major release to benefit new users.  I think they should be on by
> default on the next release.

This proposed policy change of allowing backward compatibility in the 
API to change within a major release is nothing more than smoke and 
mirrors. But I see two side effects:
1) Debian, Fedora, and perhaps other Linux distributions, see minor 
releases as maintaining backward compatibility. With Debian, they bump 
their major revision number with each break in backward compatibility. I 
didn't check, but my guess is that the version name of Lucene in Debian 
corresponds with that of Lucene itself. I'd hate for that to change. How 
would you like to see Debian to name it Lucene 4 or Lucene 5, when we 
are doing Lucene 3.x. It gets confusing. (Real example:  libsword7, 
which corresponds to the 1.5.11 release of SWORD and libsword8 
corresponds to 1.6.0.)

2) Backward compatibility of the index is at least 2 major revisions and 
that is not proposed to change. Now with this, we effectively postpone 
it indefinitely. Rather than the index being allowed to change when the 
API has broken compatibility at most 2 times, with this proposed change, 
we can break API compatibility a dozen times. At the future point where 
this policy is brought into question, with something like "Now that we 
can break backward compatibility in the API frequently, we need to 
change our policy for the index to match", then we will have come full 
circle.

At first, I liked the idea a lot, but now less so. Now I'm leaning 
toward changing major revision number when backward compatibility 
changes and for more frequent major releases if that is what it takes.

This was the thrust of my tongue-in-cheek proposal of weekly minor and 
monthly major releases.

I also share Marvin's and others' concerns about sneaky bugs introduced 
by globals. In my situation, Lucene is part of a desktop application and 
the user can create hundreds of indexes and use them within the 
application. With a *.deb or *.rpm, we'll have to specify that they 
cannot use anything but the minor release for which the application was 
designed. Before, we could say that one could drop in anything of the 
same major release number.

I don't think I am alone or unique in embedding Lucene into a desktop 
application. I know it is a part of Eclipse (at least on Fedora).

This change might have the opposite effect of making people's perception 
of Lucene as one of instability. Guard carefully against that, please!

-- DM



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


Mime
View raw message