Le mer. 30 mars 2016 à 22:56, Shawn Heisey <[email protected]> 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).
