lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <>
Subject Re: Proposal about Version API "relaxation"
Date Mon, 19 Apr 2010 08:37:36 GMT
The 'unless' part is good and in place IMO. Certainly, if sometimes in the
future Lucene moves away from segmented indexing approach into something
else, I wouldn't expect a migration tool to be introduced. So overhauling
index file format might be ok to go w/o any migration tool introduced.

But I think we tend to take it as a "all or nothing" deal. When the index
file format changed (and Mike can correct me if I'm wrong), it usually
didn't introduce such overhauling changes. For example, "flex scoring" - we
can say that a flex-scoring index should read older indexes, and if one did
not want to take advantage of that feature, one should not reindex just
because he upgrade to Lucene 4.0, for other reasons. I believe that should
be relatively easy to support.
And I think that people understand that they cannot take advantage of a new
feature until they reindex (features like flex-scoring, numeric queries
etc.) -- I just think we shouldn't *force* them to reindex just because the
indexing code now 'expects' those files/terms to be in place for regular
indexing behavior (unrelated to those advanced features).

I'm +1 for that proposal.


On Mon, Apr 19, 2010 at 11:28 AM, Doron Cohen <> wrote:

> Late joining... could we agree on an "intention" to provide an index
> migration tool when/if format back comp. has to be broken? It is not clear
> to me that this was agreed... So here is a suggestion for a revised index
> format backwards compatibility policy:
> Starting release 4.0, Lucene has a limited file formats back-compatibility
> between major versions, falling into one of the three possible levels:
> (Level 1) When possible, Version X is would be able to read indexes
> generated by any X-1 version after and including version X-1.0. (Level 2) If
> version X cannot read indexes of version X-1, the release of version X would
> be accompanied by a tool for migrating indexes from X-1 to X, unless (Level
> 3) the nature of the specific change does not allow for the development of
> such a migration tool. For the exact level of file back compatibility of a
> release see the specific release notes.
> Not sure if the "unless" part (no. 3) would ever materialize, but I think
> it provides a required freedom.
> Doron

View raw message