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]
