lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <>
Subject Re: deprecating Versions
Date Mon, 29 Nov 2010 20:43:50 GMT
On Mon, Nov 29, 2010 at 20:51, DM Smith <> wrote:
> The other thing I'd like is for the spec to be save along side of the index
> as a manifest. From earlier threads, I can see that there might need to be
> one for writing and another for reading. I'm not interested in using it to
> construct an analyzer, but to determine whether the index is invalid wrt to
> the analyzer currently in use.
You can already implement such behaviour with 3.x branch of Lucene.
It has IW.commit(Map<String, String> userdata) method, that allows you
to commit with arbitrary payload, that binds to segment and can be
read back later.

> I think there is a problem with deprecating and removing constants too.
> In trunk, which will be 4.0, it needs to be able to read and/or upgrade 2.x
> indexes. From an analyzer perspective, an index is invalid if the analyzer
> would produce a different token stream for the same input. If the 2.x
> version constants are gone, then the index built with 2.x version
> constants is no longer valid. (It might be valid, but how can one have any
> confidence of that?) Upgrading the index to the new internal format
> cannot change this. A buggy lowercase Turkish word will still be buggy
> after upgrade. (This is a 3.0 version constant that in 5.0 will still need to be around).
I think it was declared that Lucene does not provide index
compatibility across more than a single major revision.
Thus, we don't guarantee reading 2.x index with 4.0 Lucene. So, we can
drop 2.x constants and compatibility.
But we still have to support 3.x. In version 5.0 then we're dropping
3.x constants and support for bugs/deprecated
features of 3.x.

Kirill Zakharenko/Кирилл Захаренко (
Phone: +7 (495) 683-567-4
ICQ: 104465785

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message