Update: After initial reconsideration, the maintainers are willing to provide a quicker turnaround with a patch on top of cuvs-lucene 26.10 (latest released) compatible with Lucene 10.4. It won’t be a formal release but they can make it available by mid next week. Is this an option we are willing to consider for 10.1 ?
The alternative of course is to have a note in the upgrade docs for now and patch this when the official 26.12 becomes available later this year. - Rahul On Tue, Oct 13, 2026 at 1:38 PM Rahul Goswami <[email protected]> wrote: > > "They would be able to upgrade to Solr-10.1 just > > as soon as a Solr-10.1 compatable version of cuvs was available in that > > new/different repo" > How would they know? Are there releases for sandbox modules? Also, if I > understand correctly that would require users to build the jars themselves, > correct? > > Also as expressed on the RC2 thread, we don't have to delay the release - > I'll add a note (to > solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-10.adoc > ?) > about the breakage, and availability of a subsequent fix in the future. I > am told we are going to have a 10.1 RC3 anyway to accommodate other fixes > and possibly the Jetty upgrade. > > Reason I am not entirely sold on the sandbox idea is we are talking about > abruptly telling production users to monitor the sandbox based on a one > time occurence despite a known timeline for a fix...at a time when other > popular Lucene based search engines today ship with GPU acceleration > capabilities for vector search. Probably if this becomes a repeating > concern we revisit this option then? > > @Eric Pugh <[email protected]> That's a good question. I > did enquire about the possibility of expediting the fix for Lucene 10.4, > however it seems it entails more work than could be accommodated in a short > window of a week or two. But they are looking to release cuvs-lucene 26.12 > in December which will have support through Lucene 10.5 (atleast). The > planned cadence I have been made aware of is a cuvs-lucene release every > two months starting December compatible with the latest Lucene version > released as of the start of the release cycle of cuvs-lucene. > > Thanks, > Rahul > > On Tue, Oct 13, 2026 at 11:53 AM Eric Pugh <[email protected]> wrote: > >> >> >> On 2026/10/13 15:31:57 Anshum Gupta wrote: >> > +1 to Hoss’s idea of moving this to the sandbox. >> > >> > >> > Anshum Gupta >> > >> > On Tue, Oct 13, 2026 at 00:13 Jan Høydahl <[email protected]> wrote: >> > >> > > +1 to move to sandbox. Tiny feature should not hold us hostage >> > > >> > > Jan >> > > >> > > > 12. okt. 2026 kl. 23:12 skrev Chris Hostetter < >> [email protected] >> > > >: >> > > > >> > > > >> > > > The bugs found with solr/modules/cuvs in the Solr 10.1.0 RCs -- due >> to >> > > the >> > > > module depending on a thrid-party dependency that is tightly couple >> with >> > > > the Lucene version, but released by a completely different >> organization >> > > -- >> > > > is really just a new variation on the fundemental the concerns I >> raise >> > > > when cuvs was first added to Solr... >> > > > >> > > > https://issues.apache.org/jira/browse/SOLR-17892 >> > > > >> > > > I get that cuvs is a valuable feature to have, for some people, on >> some >> > > > hardware, but I really don't think it makes sense for it to be part >> of >> > > the >> > > > official Solr release -- not when it's depenencies are so tightly >> > > > intertwined (but loosly coupled) to the specific Lucene version at a >> > > very >> > > > low level. >> > > > >> > > > As Rahul indicates -- we are now facing the exact choice I warmed >> about >> > > a >> > > > year ago... >> > > > >> > > >>> In the future we (Solr) may get stuck between a rock and a hard >> place >> > > >>> when attempting a Lucene upgrades ... we will be forced to >> choose: >> > > >>> >> > > >>> - Let the Lucene upgrade be blocked indefinitely until a >> > > >>> third-party project ( cuvs-lucene ) gets around to a >> > > >>> compatible release. >> > > >>> - Stop supporting modules/cuvs in what may be a MINOR Solr >> > > >>> release, potentially screwing our users who have built indexes >> > > >>> using that module >> > > > >> > > > >> > > > I really think we need to move cuvs to either the solr-sandbox, or >> some >> > > > new purpose specific 'solr-cuvs' git repo, where it can be released >> on >> > > > it's own timeframe, dependent on when/how/if the upstream >> third-party >> > > > project (cuvs-lucene) has compatible releases for the Lucene >> version we >> > > > are using. >> > > > >> > > > >> > > > People who use Solr and do *not* use modules/cuvs should not have to >> > > > suffer delays in getting iportant bug fixes in Solr code -- or >> getting a >> > > > Solr release with a Lucene version that's already outdated -- just >> > > because >> > > > we don't want to release a Solr version with a "broken" >> modules/cuvs. >> > > > >> > > > >> > > > -Hoss >> > > > http://www.lucidworks.com/ >> > > > >> > > > >> > > > >> > > > >> > > > On Sun, 11 Oct 2026, Rahul Goswami wrote: >> > > > >> > > > : Date: Sun, 11 Oct 2026 17:08:02 -0400 >> > > > : From: Rahul Goswami <[email protected]> >> > > > : Reply-To: [email protected] >> > > > : To: [email protected] >> > > > : Subject: Re: [VOTE] Release Solr 10.1.0 RC2 >> > > > : >> > > > : Tried the RC. The cuvs module seems to be broken. Indexing fails >> on a >> > > GPU >> > > > : enabled machine due to API incompatibility between cuvs-lucene and >> > > Lucene >> > > > : 10.4. >> > > > : Currently no available compatible cuvs-lucene version exists for >> Lucene >> > > > : 10.4 and is expected to be available by December this year. >> > > > : >> > > > : If there is agreement, I could spend the effort on rolling Solr >> back to >> > > > : Lucene 10.3.2 where I have validated cuvs to work (which was also >> the >> > > > : Lucene version we were on prior to 10.4). >> > > > : >> > > > : Thoughts? >> > > > : >> > > > : 2026-10-10 20:57:58.804 WARN (qtp166454155-71) [] >> > > o.e.j.e.s.ServletChannel >> > > > : /solr/vectors/update >> > > > : *java.lang.NoSuchMethodError: 'int[] >> > > > : >> > > >> org.apache.lucene.util.hnsw.HnswGraph$NodesIterator.getSortedNodes(org.apache.lucene.util.hnsw.HnswGraph$NodesIterator)'* >> > > > : at >> > > > : >> > > >> com.nvidia.cuvs.lucene.Lucene99AcceleratedHNSWVectorsWriter.writeGraph(Lucene99AcceleratedHNSWVectorsWriter.java:444) >> > > > : at >> > > > : >> > > >> com.nvidia.cuvs.lucene.Lucene99AcceleratedHNSWVectorsWriter.writeFieldInternal(Lucene99AcceleratedHNSWVectorsWriter.java:230) >> > > > : at >> > > > : >> > > >> com.nvidia.cuvs.lucene.Lucene99AcceleratedHNSWVectorsWriter.writeField(Lucene99AcceleratedHNSWVectorsWriter.java:502) >> > > > : at >> > > > : >> > > >> com.nvidia.cuvs.lucene.Lucene99AcceleratedHNSWVectorsWriter.flush(Lucene99AcceleratedHNSWVectorsWriter.java:494) >> > > > : at >> > > > : >> > > >> org.apache.lucene.codecs.perfield.PerFieldKnnVectorsFormat$FieldsWriter.flush(PerFieldKnnVectorsFormat.java:120) >> > > > : at >> > > > : >> > > >> org.apache.lucene.index.VectorValuesConsumer.flush(VectorValuesConsumer.java:76) >> > > > : at >> org.apache.lucene.index.IndexingChain.flush(IndexingChain.java:305) >> > > > : at >> > > > : >> > > >> org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:456) >> > > > : at >> > > >> org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:502) >> > > > : at >> > > > : >> > > >> org.apache.lucene.index.DocumentsWriter.maybeFlush(DocumentsWriter.java:456) >> > > > : at >> > > > : >> > > >> org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:649) >> > > > : at >> > > > : >> > > >> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:3712) >> > > > : at >> > > >> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:4160) >> > > > : at >> org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:4122) >> > > > : at >> > > > : >> > > >> org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:872) >> > > > : at >> > > > : >> > > >> org.apache.solr.update.processor.RunUpdateProcessorFactory$RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:100) >> > > > : at >> > > > : >> > > >> org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:66) >> > > > : at >> > > > : >> > > >> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor >> > > > : >> > > > : - Rahul >> > > > : >> > > > : On Sat, Oct 10, 2026 at 5:57 PM Jan Høydahl <[email protected]> >> wrote: >> > > > : >> > > > : > The changelog lists "Dependency Upgrades (61 changes)" >> > > > : > I thought we were to hand edit and de-duplicate that list. >> > > > : > >> > > > : > PS: Jetty 12.1.14 hits branch_10x soon, hope it can make it if >> > > there's a >> > > > : > respin. >> > > > : > >> > > > : > Jan >> > > > : > >> > > > : > > 10. okt. 2026 kl. 15:48 skrev Andrzej Białecki <[email protected] >> >: >> > > > : > > >> > > > : > > Please vote for release candidate 2 for Solr 10.1.0 >> > > > : > > >> > > > : > > The artifacts can be downloaded from: >> > > > : > > >> > > > : > >> > > >> https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC2-rev-dfda5e1d4821958e60d13aa5ce3a0d4992319ed1 >> > > > : > > >> > > > : > > You can run the smoke tester directly with this command: >> > > > : > > >> > > > : > > python3 -u dev-tools/scripts/smokeTestRelease.py \ >> > > > : > > >> > > > : > >> > > >> https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC2-rev-dfda5e1d4821958e60d13aa5ce3a0d4992319ed1 >> > > > : > > >> > > > : > > You can build a release-candidate of the official docker >> images >> > > (full & >> > > > : > slim) using the following command: >> > > > : > > >> > > > : > > SOLR_DOWNLOAD_SERVER= >> > > > : > >> > > >> https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC2-rev-dfda5e1d4821958e60d13aa5ce3a0d4992319ed1/solr >> > > > : > && \ >> > > > : > > docker build >> > > > : > $SOLR_DOWNLOAD_SERVER/10.1.0/docker/Dockerfile.official-full \ >> > > > : > > --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \ >> > > > : > > -t solr-rc:10.1.0-2 && \ >> > > > : > > docker build >> > > > : > $SOLR_DOWNLOAD_SERVER/10.1.0/docker/Dockerfile.official-slim \ >> > > > : > > --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \ >> > > > : > > -t solr-rc:10.1.0-2-slim >> > > > : > > >> > > > : > > The vote will be open for 72 hours (not including the Sunday >> and >> > > > : > Columbus Day), i.e. until 2026-10-15 15:00 UTC. >> > > > : > > >> > > > : > > [ ] +1 approve >> > > > : > > [ ] +0 no opinion >> > > > : > > [ ] -1 disapprove (and reason why) >> > > > : > > >> > > > : > > Here is my +1 >> > > > : > > ---- >> > > > : > > >> > > > : > > Cheers, >> > > > : > > Andrzej >> > > > : > > >> > > --------------------------------------------------------------------- >> > > > : > > To unsubscribe, e-mail: [email protected] >> > > > : > > For additional commands, e-mail: [email protected] >> > > > : > > >> > > > : > >> > > > : > >> > > > : > >> --------------------------------------------------------------------- >> > > > : > To unsubscribe, e-mail: [email protected] >> > > > : > For additional commands, e-mail: [email protected] >> > > > : > >> > > > : > >> > > > : >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: [email protected] >> > > > For additional commands, e-mail: [email protected] >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: [email protected] >> > > For additional commands, e-mail: [email protected] >> > > >> > > >> > >> What about highlighting to that community that we need a 10.4 release >> ASAP, and seeing if that changes their timeline. Judinging from the github >> issue, they are filling in a number of missing verion releases, which of >> couse makes it more work then just cutting a 10.4 release. If they >> committed to releasing a 10.4 in the next week, would that change things >> for us? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
