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
