+1 to 'B'! On Wed, Feb 25, 2026 at 5:38 PM Jan Høydahl <[email protected]> wrote: > > I too think the only way for us is B). But perhaps improve or documentation > and explicitly mention the risk of not being able to roll back an upgrade if > there has been a lucene bump. We have a dev-docs/lucene-upgrade.md that could > be updated, and the RM docs could also include a reminder to include in > upgrade-notes. > > Wrt my customer, Solr is 90% certain NOT the root cause, but they wanted to > roll back some recently upgraded components proactively as part of analysis. > Solr Operator did a great job of halting the rolling downgrade and broght it > back to 9.10.1 in a few minutes too. But if we DID discover a serious flaw in > a brand new Solr version, and that version also brought in a new minor Lucene > version, it'd be a one-way street with potential full re-index or > hot-patching a self-built fix-version... > > Jan > > > 25. feb. 2026 kl. 22:20 skrev David Smiley <[email protected]>: > > > > Definitely "B"; "A" would hold Solr back! > > And to help that along, I believe there are Lucene upgrade notes that Solr > > has somewhere. Those notes should include a step to check for an > > index/codec change, and if so then to ensure this is strongly announced in > > the upgrade notes. > > > > Rahul: Lucene's current codec is held inside lucene-core.jar... and we > > definitely can't have multiple lucene-core.jar. I think it's pretty shaky > > ground to pursue taking the "write" support of an older JAR. There are > > very low level API changes that change internally but are used by codecs, > > like for PackedInt or whatever. > > > > On Wed, Feb 25, 2026 at 9:52 AM Jan Høydahl <[email protected]> wrote: > > > >> Hi, > >> > >> At a customer we upgraded from Solr 9.8.1 to 9.10.1 recently to stay on > >> top of CVEs etc. > >> Today we had the need to roll back Solr due to some crash situation. > >> But after downgrading to 9.8.1 the nodes don't get up with errors about > >> missing codec "Lucene912". > >> > >> Par of Solr/Lucene's back-compat promise is that we won't do breaking > >> chagnes in minor versions. > >> But this kind of codec changes between minor versions breaks the ability > >> to downgrade - you need a full reindex. > >> I find a related discussion in Lucene about this > >> https://github.com/apache/lucene/issues/14623#issuecomment-2866257196 > >> > >> We currently do not clearly document this limiation in RefGuide. > >> > >> In my eyes we (Solr) have two choices: > >> > >> A) Stay at the same lucene minor version throughout a Solr major version > >> and keep back-compat also for downgrades > >> B) Start doumenting in release notes when a new lucene version will > >> prevent future downgrade, and advise users to back up their index before > >> upgrading if they want the ability to roll back. > >> > >> Thoughts? > >> > >> Jan > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
