Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0 will be able to read Lucene 5.0 indexes. The only thing that we don't guarantee support for is API, which isn't the case here.
So what's in 6.0 that can't read a 5.x Solr. It can't be the index format since that's supported by Lucene. Is it the ZK format? If so, should we try to "version" it so that a 6.0 code can read a 5.x version? Is it something else / additionally? Shai On Tue, Feb 23, 2016 at 7:06 PM Mark Miller <markrmil...@gmail.com> wrote: > Yes, we are allowed wide berth to break backcompat across major versions > and we cannot support rolling updates for the same reason Lucene stopped > trying to do full back compat across major versions. Without, we can't > properly innovate in the code or fix past mistakes and would also burn lots > of cycles we don't have on crazy, "sophisticated" back compat layers. > > We don't even really support rolling updates between major versions. We > make a simple best effort. Until we have tests, it's going to be a shaky > affair. There is a JIRA open now working on some testing I believe. > > - Mark > > On Tue, Feb 23, 2016 at 11:29 AM Shai Erera <ser...@gmail.com> wrote: > >> Hi >> >> I read in few emails/issue comments that rolling upgrades from 5.x to 6.0 >> isn't supported. Is it really the case? Does it mean that anyone who has a >> 5.x Solr cluster *must* incur down time when upgrading to 6.0? >> >> If this is really the case, can someone list the known issues/reasons for >> that?Can we do something about it, e.g. in a subsequent 5.6 release that >> will allow rolling upgrades (like the 5.4.1 fix that allowed rolling >> upgrades from pre-5.4 to 5.4)? >> >> I feel it's odd (and may not be taken well) if we force users to take >> down their entire cluster if they want to upgrade to 6.0. Definitely feels >> like it will also slow down 6.0 adoption. >> >> And if nothing can be done, what's the recommended way then to upgrade to >> 6.0? >> >> Shai >> > -- > - Mark > about.me/markrmiller >
