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. Shai On Mon, Apr 19, 2010 at 11:28 AM, Doron Cohen <cdor...@gmail.com> 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 >
