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 Thu, 21 May 2009 16:46:20 GMT
Michael McCandless wrote:
> On Thu, May 21, 2009 at 8:24 AM, DM Smith <dmsmith555@gmail.com> wrote:
>   
>> On May 21, 2009, at 7:17 AM, Michael McCandless wrote:
>>
>>     
>>>  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.
>>>       
>> I'd reverse 1 and 2 and note in 1 that the old behavior might be deprecated.
>>     
>
> OK.
>
>   
>>>  2) An API, once released as deprecated, is fair game to be removed
>>>    in the next minor release.
>>>       
>> I presume you mean that it will be present for at least one full minor
>> release. So, if at 3.1.5 a deprecation is introduced, then it won't be
>> removed until 3.3 at the earliest, because 3.2 was the first minor release
>> in which it appeared at the start. I don't think it is fair to expect users
>> to get every last point release.
>>     
>
> Right.
>
>   
>>> We still only make bug fixes on point releases, support the index file
>>> format until the next major release -- those don't change.
>>>       
>> Is it just the index file format? I would hope that the behavior of filters,
>> analyzers and such would not change so as to invalidate an index.
>>     
>
> Can you give an example of such changes?  EG if we fix a bug in
> StandardAnalyzer, we will default it to fixed for new users and expect
> you on upgrading to read CHANGES.txt and change your app to set that
> setting to its non-defaulted value.
>   
I guess I'm not too concerned with bug fixes. I'm kind of a nut when it 
comes to correctness. But, I'd want to know that such a bug broke strict 
backward compatibility. I guess I don't want backward compatibility to 
get too much in the way of fixing bugs. (I think sometimes it has.) I 
wouldn't expect a compatibility flag to preserve buggy behavior. I guess 
I'm willing to go to extra effort to work with bug fixes. But I wouldn't 
expect others to feel the same way.

Off the top of my head, in addition to Robert's stop word list, let's 
say that the filter that strips accents (I can't remember the name) is 
changed to be more than Latin-1 to ASCII folding. That would invalidate 
existing indexes.

Or a new and improved filter is created to replace a class I use and the 
old class is deprecated. If that old class goes away, my index is 
invalidated.

So if the stream of tokens out of an analyzer changes or the results of 
a filter is different, an index built with them is invalidated. If the 
output remains the same, I shouldn't care what has changed internally 
and probably don't care if the API has changed.

I don't know if it matters to this discussion, but there's a lot in 
contrib that people (of which I am one :) expect to be stable. I'm 
looking forward to the repackaging effort.

-- 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