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 07:50:02 GMT
bq. not true. at some point you have to re-index, this isn't database
software. i suggest between major versions!

API/index compatibility was discussed some time ago, and there was a
kind of consensus I believe.
For APIs:
* Compatibility is guaranteed across minor releases, eg - within 2.x,
3.x, 4.x branches.
* We reserve the right to break it for major releases, eg - 4.x is a
break from 3.x. Though still try to forewarn people with deprecations
in previous branch, if possible.

And for indexes:
* Index compatibility is guaranteed across two adjacent major
releases. eg 2.x -> 3.x, 3.x -> 4.x.
 That includes both binary compat - codecs, and semantic compat -
analyzers (if appropriate Version is used).
* Older releases are most probably unsupported.
 e.g. 4.x still supports shared docstores for reading, though never
writes them. 5.x won't read them either, so you'll have to at least
fully optimize your 3.x indexes when going through 4.x to 5.x.

On Mon, Nov 29, 2010 at 05:35, Robert Muir <> wrote:
> On Sat, Nov 27, 2010 at 3:44 PM, Earwin Burrfoot <> wrote:
>> I think we should deprecate and remove Version constants as Lucene progresses?
> well one idea was that we would release analyzers with their own
> version numbers... e.g. instead of Version 4.0 you use
> analyzers-4.0.jar.
> This way you could upgrade lucene-core.jar to say, 4.5 or whatever,
> and still have your exact same index compatibility (same bytecode!)
>> Going with this, we should deprecate 3x in trunk and delete 2x. In 3x
>> branch, we should deprecate 2x.
> the problem as i understand it, is that people never want to reindex.
> e.g. they want to upgrade to 2.x, upgrade to 3.x, and then upgrade to
> 4.x and never re-analyze text.
> with the rest of the index (lists of integers), things like this can
> be converted losslessly, but analyzers do a lossy conversion...
> so it seems some people think we have this 'perpetual' backwards
> compatibility at the moment... not true. at some point you have to
> re-index, this isn't database software. i suggest between major
> versions!
> bottom line: i agree with you that we really need to clean house in
> trunk, except to say that Version constants should be removed
> completely too and replaced with 'real versions' if possible.
> the other major user of Version is QueryParser, perhaps if it gets
> yanked out of lucene core, we would do the same.
> we just have to figure out how the module releasing will work: should we:
> 1. do nothing yet: analyzers-4.0.jar have all the cruft, and then we
> can finally remove Version in analyzers-4.1?
> 2. backport the whole analyzers module to 3.x, keep the cruft there,
> remove Version in trunk now?
> 3. just say screw it and clean house in trunk, like we did for the
> rest of the code?
> 4. <other ideas>
> and how long should an analyzers-jar file be "valid" for anyway?
> eventually, no matter how clean the separation is with trunk, software
> interfaces are going to have to break.
> the same situation will happen if we try to modularize lucene in other
> ways so we need to figure these things out. again i suggest for the
> long term we should look at breaking in major versions,
> its what people are used to with other software.
> but for now, I think we at least need to deprecate Version_3.x in
> trunk, and Version_2.x in branch_3x, and remove Version_2.x in trunk
> completely as you suggest.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

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

View raw message