On 3/30/2016 10:43 AM, Adrien Grand wrote: > I think marking the legacy fields/queries as deprecated in Lucene in > 6.0 is the right thing to do in order to encourage users to migrate to > the new points API. If Solr needs to keep them around for 7.x, it > would be fine to move them to solr/ instead of lucene/ instead of a > hard removal. Given that it works on top of the postings API, it would > not break.
Encouraging users to migrate to better APIs is a great idea. I'm sure we'll update Solr's examples to use new classes that leverage the points API, but at the moment, we do not have time before the 6.0.0 release to do this. This puts Solr in an awkward position. 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. Option 1 should not be a major hardship for Lucene. Users can still use the new API, and such use can be encouraged by examples, documentation, and community activity. Version 7.0 would provide further encouragement, and I don't see any reason we can't work towards a quick 7.0 release and a relatively short lifetime for 6.x. 5.x had a much shorter lifetime than 4.x did. Option 2 would be disappointing for everyone, and even though 6.0 would probably STILL be the fastest major release in recent project history even with this delay, I am expecting significant pressure against it. Option 3 would be a major disappointment for Solr, but I think it would be better for the integrity of the project than our current trajectory. Option 4 is more than a little ugly, which is why it's in 4th place. Assuming the postings API would work correctly after the package move, it would fix the problem. I do not like option 5 at all. This community works by consensus, so my personal preference on the options above is not worth very much. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
