On 3/31/2016 10:02 AM, Ishan Chattopadhyaya wrote: > > What bothers me is that the 6.0 user will have to change their > > schema and completely reindex, even if they upgrade to a newer 6.x > > version before going to 7.0. > > AFAICT, I think we can continue to have Trie* fields well into 7.x (by > pulling the Legacy numerics into Solr at 7.0 release), so as not to > force users to change schema or reindex if they don't want to. > Additional Points* fields would be there (at some 6.x onwards) for > whoever wants performance benefits, and we can make that as the > default in a 7.0 schema.
Moving the legacy numerics into Solr is not my ideal solution to the 6.0->7.0 compatibility issue, but there isn't much of a downside, so I'm willing to work with it. I also think it's the solution least likely to encounter opposition. Should I start a VOTE thread so Solr can make a formal decision? If moving classes is the plan, I believe we should do this in master at the same time we implement points-based field classes in 6.x. They should remain deprecated, to be completely removed in 8.0. IMHO, switching to new points-based field classes in example schemas should happen in a 6.x release, but it should not happen in the same release that introduces the new classes. Waiting at least two minor releases seems prudent. We need time to battle-test them before we make them default. I do think that they should be tested further before 7.0, which making them default in a later 6.x would accomplish. On the subject of a VOTE thread, I think there are at least two separate things to discuss and decide: * Separating Lucene/Solr releases. I've thought of a couple of approaches for this, things that need discussing. * Solr: deciding how to solve 6.0->7.0 compatibility. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
