[LUCENE-5940] change index backwards compatibility policy.

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Lucene Fields: New
• Assignee: Unassigned
• Reporter: Robert Muir
• Created: 11/Sep/14 14:24
• Updated: 28/Aug/22 14:15

Description

Currently, our index backwards compatibility is unmanageable. The length of time in which we must support old indexes is simply too long.

The index back compat works like this: everyone wants it, but there are frequently bugs, and when push comes to shove, its not a very sexy thing to work on/fix, so its hard to get any help.

Currently our back compat "promise" is just a broken promise, because we cannot actually guarantee it for these reasons.

I propose we scale back the length of time for which we must support old indexes.

Issue Links

• relates to: LUCENE-5492 IndexFileDeleter AssertionError in presence of *_upgraded.si files
• relates to: LUCENE-5907 closing NRT reader after upgrading from 3.x index can cause index corruption
• relates to: LUCENE-5934 4.10 broke backwards compatibility for 4.0 beta & 4.0-release indexes
• relates to: LUCENE-5939 4.10.1 cannot read 4.10 indexes
• relates to: LUCENE-5377 IW.addIndexes(Dir[]) causes silent index corruption
• relates to: LUCENE-5462 Lucene 3.x producers shouldn't use RamUsageEstimator to estimate size
• relates to: LUCENE-5125 Codec classes/packages that do not provide (automatic) file format back compat need to be more explicit about this in javadocs