I hope that we have a shorter gap between the release of Lucene 11 and the first release of Solr 11 this time around. Especially as it feels like the pace of Lucene major version bumps is moving closer to a 12 to 18 month cycle… So this is exciting.
I was going to ask if we wanted to revisit the past pattern of bumping Solr major version when we move to major version bumps of Lucene, but I guess because of the Java 25 requirement that is moot for this cycle. Since as long as we bump major versions of Java as a base requirement then we need to bump major version of Solr… One area that would help us would be to get the rest of the tooling in Solr-orbit over the finish line so we can build more confidence in the performance characteristics of Solr on newer Lucene versions. It would be great to start getting some comparative runs of Solr 10/Java 21 and Solr 11/Java 25….. Which needs more sophisticated Solr Orbit workloads. https://github.com/apache/solr-orbit https://github.com/apache/solr-orbit-workloads Eric > On Jul 22, 2026, at 10:58 AM, Serhiy Bzhezytskyy > <[email protected]> wrote: > > Thanks David! > > Created SOLR-18313 (https://issues.apache.org/jira/browse/SOLR-18313 > <https://issues.apache.org/jira/browse/SOLR-18313>) and > opened https://github.com/apache/solr/pull/4651 > <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 > > Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
