On Sat, Nov 27, 2010 at 3:44 PM, Earwin Burrfoot <ear...@gmail.com> 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
