Thanks for looking ahead at what's coming! On Wed, Jul 22, 2026 at 5:28 AM Serhiy Bzhezytskyy < [email protected]> wrote:
> Decision 1 — the Java 25 baseline. Yup; Solr 11 will be compelled to adopt Lucene's Java baseline. When we upgrade, anyway. This would be a good preparatory first step for Solr *prior* to adopting Lucene 11. However, I prefer we delay this until Lucene 11 is actually released. Divergences across Solr branches contribute to backport pain without *yet* serving a purpose. > Decision 2 — compound-file config. > > Lucene 11 removed the merge-policy maxMergeAtOnce and noCFSRatio settings, > and moved compound-file selection onto the codec's CompoundFormat. > > Two user-facing consequences: > > (a) a solrconfig.xml still setting those merge-policy options would fail > core init — in my branch I made Solr ignore-with-warning instead, so > existing configs keep loading. Is warn-and-ignore the behavior we want, or > should it hard-fail with a migration message? > > (b) useCompoundFile no longer reaches merged segments on its own (only > flushed ones), so I bridged it to the codec and added a maxCFSSegmentSizeMB > option as the noCFSRatio replacement. Sanity-check welcome on that > approach. > Sounds reasonable but I haven't looked. ... > Most of it is 11-only by design, but a couple compile against current main > today: > > change 10.4 10.5 10.6 > 11-only > > --------------------------------------------------------- ---- ---- > ------- > > SortField.setMissingValue -> constructor arg yes yes yes no > > Operations.concatenate(a,b) -> concatenate(List) yes yes yes no > ... > > So the first two rows are adoptable now — I verified they build against > current Solr main (on Lucene 10.4). > Fine idea as a preparatory step. > If there's interest I'm happy to split them into a small "prep for Lucene > 11" PR separate from the version bump. Please; thank you! ~ David
