On Fri, Jul 19, 2013 at 11:18 AM, Shai Erera <[email protected]> wrote:
I feel that we should offer both... somehow. If we make the default Codec > conservative, and all the "good stuff" experimental, people might prefer to > use a conservative Lucene (just because the other path means being > adventurous or very expert), and perhaps then we'll get conservative > results compared to others... > > We should at least try not to break back compat when it's not necessary. > Eg if the format changes such that we can still keep the old format for old > indexes (read-only) with a different name, then we should consider it. I > know it means we'll need to maintain two Codecs wrt API changes, but I hope > that's not common. > > I don't agree with this, sorry. a lot of that experimental stuff is experimental because its still in flux. if we are going to provide file back compat for something, this means: * thoroughly documenting the file formats involved * adding and maintaining the appropriate indexes to TestBackwardsCompatibility * doing copy-on-write whenever we want to make a change to the codec and dragging lots of baggage through 2 major release cycles. * makes it harder to do major refactoring or fixing (take a look at some of the special cases and backwards stuff to make Lucene3xCodec work!!!!) Its nice to have alternative codecs for people to play around with in the codecs/ package, but that doesnt need to equate to additional back compat hell. Its a serious committment and I think we should just support our official file format this way. But this is a totally separate discussion from what our defaults should be.
