Andrzej, that makes sense, and I agree with you. Let Solr 10.1 proceed and we incorporate an official cuvs-lucene patch later down the line once it becomes available. I'll submit a PR for the doc change for 10.1.
- Rahul On Wed, Oct 14, 2026 at 5:59 AM Andrzej Białecki <[email protected]> wrote: > I don’t feel comfortable with waiting another week and then including a > rushed patch release. > > I think it’s much better for everyone involved to just accept the state of > things as they are - BUT document it well AND provide a clear procedure on > what bits to replace once an official release becomes available. > > Cheers, > Andrzej > > > On 14 Oct 2026, at 02:22, Rahul Goswami <[email protected]> wrote: > > > > 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] > >>> > >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
