Does Solr need its own MIGRATE.txt file? Maybe not for 6.0, but probably for 6.x when any Solr field type changes occur.
Right now, MIGRATE.txt belongs to the lucene package: https://github.com/apache/lucene-solr/blob/branch_6_0/lucene/MIGRATE.txt The migration comments related to numeric fields don't really say anything related to Solr users directly: "# PointValues replaces NumericField (LUCENE-6917) PointValues provides faster indexing and searching, a smaller index size, and less heap used at search time. See org.apache.lucene.index.PointValues for an introduction. Legacy numeric encodings from previous versions of Lucene are deprecated as LegacyIntField, LegacyFloatField, LegacyLongField, and LegacyDoubleField, and can be searched with LegacyNumericRangeQuery." I mean, Solr users deal with solr.TrieIntField, et al, which are Solr classes that internally map to Lucene field classes. Since the 6.0 Solr code has already been "migrated" to use the LegacyTrieXxxField types, which should be fully compatible with 5.x, Solr should initially be fine with 6.0. See the createField method of Solr's TrieField: https://github.com/apache/lucene-solr/blob/branch_6_0/solr/core/src/java/org/apache/solr/schema/TrieField.java -- Jack Krupansky On Wed, Mar 30, 2016 at 4:56 PM, Shawn Heisey <[email protected]> wrote: > 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] > >
