lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Making DiskDVFormat not experimental
Date Fri, 19 Jul 2013 16:19:06 GMT
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

On Fri, Jul 19, 2013 at 11:27 AM, Robert Muir <> wrote:
> On Fri, Jul 19, 2013 at 11:18 AM, Shai Erera <> 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:
For additional commands, e-mail:

View raw message