This causes a lot of copy-on-write/baggage for things in heavy flux. I don't understand why we need to go overboard when a user can migrate their index to the official format with addIndexes...
if someone wants to make a command-line tool around addIndexes(Reader) to assist in that, I'm all for that. On Fri, Jul 19, 2013 at 12:19 PM, Michael McCandless < [email protected]> wrote: > Maybe, for the experimental formats with no back compat, we could at > least rename them when there is a breaking change? > > This way, assuming there were no changes to the codec APIs, an app > could upgrade to Lucene 4.4 while continuing to use e.g. > Disk42DocValuesFormat, without having CLASSPATH horrors. > > Ie they could decouple the decision of upgrading the index from > upgrading the JARs. > > When they are ready to upgrade, they could then switch to > Disk44DocValuesFormat. > > Mike McCandless > > http://blog.mikemccandless.com > > > On Fri, Jul 19, 2013 at 11:27 AM, Robert Muir <[email protected]> wrote: > > > > > > 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. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
