lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: 6.0 Release
Date Fri, 01 Apr 2016 00:17:10 GMT
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

* Solr: deciding how to solve 6.0->7.0 compatibility.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message