I see a more difficult problem in the opposite - say, a new Query that requires something from the index that older indexes (codecs) don't have. Then running such a query would result in, I assume, an exception? Things get awkward when you have existing systems that wish to gradually upgrade so that some segments are in older codecs and newer segments are in newer codecs.
But in general I'm quite ok with keeping N-2 compatibility if it's not too much trouble. D. On Wed, Jan 6, 2021 at 4:21 PM Michael Sokolov <msoko...@gmail.com> wrote: > In practice what would this mean? We relax the restriction that David > mentions, and we keep old codecs around in backwards-codecs for two > major releases instead of one? Are there other implications? Suppose > we had a Query that relied on a specific index format, which gets > retired. We keep the index format code around - do we also need to > remember to maintain the old Query? > > -Mike > > On Wed, Jan 6, 2021 at 4:41 AM Simon Willnauer > <simon.willna...@gmail.com> wrote: > > > > Hello all, > > > > Currently Lucene supports reading and writing indices that have been > > created with the current or previous (N-1) version of Lucene. Lucene > > refuses to open an index created by N-2 or earlier versions. > > I would like to propose that Lucene adds support for opening indices > > created by version N-2 in read-only mode. Here's what I have in mind: > > > > - Read-only support. You can open a reader on an index created by > > version N-2, but you cannot open an IndexWriter on it, meaning that > > you can neither delete, update, add documents or force-merge N-2 > > indices. > > > > - File-format compatibility only. File-format compatibility enables > > reading the content of old indices, but not more. Everything that is > > done on top of file formats like analysis or the encoding of length > > normalization factors is not guaranteed and only supported on a > > best-effort basis. > > > > The reason I came up with these limitations is because I wanted to > > make the scope minimal in order to retain Lucene's ability to move > > forward. If there is consensus to move forward with this, I would like > > to target Lucene 9.0 with this change. > > > > Simon > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
