lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <>
Subject Re: deprecating Versions
Date Mon, 29 Nov 2010 02:35:45 GMT
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
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

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:

View raw message