> 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.


On Thu, Mar 31, 2016 at 9:24 PM, Shawn Heisey <[email protected]> wrote:

> On 3/30/2016 10:31 PM, David Smiley wrote:
> > I disagree with Shawn about #5, that a user with a Solr 6.0 index must
> > be able to upgrade straight to 7.0.  Perhaps this has been the case
> > for every major release in the past, and it would be nice if it
> > continues if for no other reason than consistency.  But, IMO, that's
> > kind of cosmetic -- it isn't important.  What matters is that an
> > eventual 6.x release occurs that allows someone to upgrade to 7.0 --
> > that there's a path forward.  And that one can always upgrade from one
> > 6.x release to any greater 6.x release.
>
> I'm not bothered by the idea that somebody might need to do a two-stage
> upgrade.  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.
>
> For me, this isn't really a worry, because I always reindex when
> upgrading.  We've got at least one user with a 10TB SolrCloud index
> containing billions of documents.  Reindexing on that scale might take a
> few months.
>
> > Quoting Adrien:
> > bq. 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.
> >
> > +1 to that!  I've had that thought.  It would be awesome for Solr to
> > release when it feels it's right, independently of Lucene.  If that's
> > too difficult/problematic then perhaps keep synchronizing releases but
> > allow Lucene & Solr's release version to vary.    Then we'd be having
> > a Solr 5.6 release here.
>
> I'm ambivalent about a separate release cycle.  I like the synchronized
> releases, but I can also see the advantages to separating them.  It
> would help with LUCENE-5589 and friends.
>
> Thanks,
> Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to