Michael McCandless wrote:
On Thu, May 21, 2009 at 8:24 AM, DM Smith <dmsmith...@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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
