: I share the underlying concern about tight, low-level coupling between : cuvs-lucene and specific Lucene versions. However, cuvs already shipped as : part of Solr 10.0. Pulling the module out into a separate repo now would : strand those users for subsequent releases.
PUlling the module out would not harm the existing cuvs uses anymore then they are already harmed: 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 -- that's no different then if we delay a Solr-10.1 release until there is a a Solr-10.1 compatable version of cuvs we can commit to the main solr repo. But if we *do* move cuvs to a seperate repo, everybody *else* who wants Solr-10.1 can upgrade *today* (and get all the goodness of Lucene-10.4) w/o needing to wait until december. : Also, this particular breakage is temporary. The incompatibility in the I'm pretty sure that's what folks said the last 2 times cuvs broke in a weird way. : https://github.com/NVIDIA/cuvs/pull/2702), and they intend to keep a : regular cadence aligned with Lucene releases going forward. If that holds, We should not have to depend on the reliability of a third-party project's release schedule to decide if/when we can release (or if/when we can upgrade our Lucene version) : users should only need to wait for a Solr 10.1.1 or Solr 10.2 to get a : working cuvs again which is not unreasonable. Solr 10.1.0 can ship. How is that situation any differnet if cuvs is released from a different repo -- when it's ready -- and users can drop the (third-party) module/cuvs files into their Solr modules directory ? -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
