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]
