Thanks David! Created SOLR-18313 (https://issues.apache.org/jira/browse/SOLR-18313) and opened https://github.com/apache/solr/pull/4651 for the two forward-compatible changes — the SortField missing-value constructor and Operations.concatenate(List). No behavior change; gradlew check is green on current main.
Agreed on holding the Java 25 bump until it serves a purpose — no point paying the backport cost early. For what it's worth, there's no branch_11x cut on the Lucene side yet and 10.6 is still in progress, so 11 doesn't look imminent regardless. On Wed, 22 Jul 2026 at 16:13, David Smiley <[email protected]> wrote: > 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 >
