lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack Krupansky <>
Subject Re: 6.0 Release
Date Wed, 30 Mar 2016 23:52:58 GMT
Adrien, sure, Solr could take ownership of the so-called legacy (trie)
numerics, but then what would Elasticsearch do for its users when ES
upgrades to Lucene 7.0 which would then no longer have the code to handle
existing Trie-based indexes? Would ES then start depending on Solr?! Or is
ES planning on somehow automatically migrating ES 2.x indexes from Trie
numeric fields to PointValues?

Is ES going to do its own Trie to PV converter?

Will Solr also need to do its own Trie to PV converter for 7.0?

It does seem very odd to me that the Lucene guys have made this switch to
PV without any migration tool for existing Trie indexes.

-- Jack Krupansky

On Wed, Mar 30, 2016 at 6:56 PM, Adrien Grand <> wrote:

> Le mer. 30 mars 2016 à 22:56, Shawn Heisey <> a écrit :
>> These are the choices I see to address the problem, in decreasing order
>> of personal preference:
>> 1) Revert LUCENE-6917 in the 6.x versions, move the deprecation to master.
>> 2) Delay the Lucene/Solr 6.0.0 release so Solr has new field classes and
>> updated examples.
>> 3) Keep to the schedule for the Lucene 6.0.0 release, but do NOT release
>> Solr 6.0.0.  Do a synchronized Lucene/Solr release of 6.0.1 or 6.1.0
>> with new Solr classes and examples.
>> 4) Move the deprecated Lucene classes to the Solr 7.0 package space
>> (still deprecated) as suggested by Adrien.  Fully remove them in 8.0.
>> 5) Compromise Solr's historical guarantees of major version backward
>> compatibility.
> I am confused why you put 1 before 4: to me they are the same from a Solr
> perspective, and 4 is better than 1 from a Lucene perspective since it
> makes the path forward clearer?
> I think the only reasonable alternative to 4 is 2, which like you said
> would be disappointing. I don't think anybody wants 5, and 3 feels awkward
> to me. Detour: In the future I wonder that we should consider having
> separate release cycles again. In addition to giving Solr more time to use
> new Lucene features like here, it would also remove the issue that we had
> when releasing 5.3.2 after 5.4.0, which makes perfectly sense from a Solr
> perspective but not from Lucene since it introduces blind spots in the
> testing of index backward compatibility.
> Back to the current issue, my preference would go for 4. I could be wrong
> but I think it is also consistent with the fact that Solr historically kept
> compatibility for a longer time than Lucene (eg. by still supporting
> IntField or allowing uninverting out of the box).

View raw message