Hi, > One important reason why separate repo for solr-extras is a good idea, as > opposed to conrib modules, is that separate repo can be used to test against > many Solr versions. Imagine a component that works across Solr versions 6x > through 9x from day one. I can't imagine such a component being part of the > lucene-solr repo itself.
For independent tools such as solr-operator or prometheus-exporter, or some future standalone DIH, it makes sense with separate repo and release cadence. However it will be much easier for our 1st party packages to remain in the monorepo, keeping all tests in-sync with core. > Also, today, contrib modules are shipped with Solr, which we don't want for > new things we might want to build. Remember that Solr main tarball does not need to include all our packages. We can easily extend our releae process to release e.g. solr-cell-9.5, solr-analysis-9.5, solr-auth-xyz-9.5 in our release repo together with the 9.5 release, i.e. release every package with every Solr version. Then we do not need a compatibility matrix, since users will be able to install the latest package. And each release can ship with a pre-installed package repo for that version. I imagine it will be very very hard to provide cross-major-version compatibility for some plugins. It may get easier as more higher-level APIs are build to shield plugins from low-level inner code, but we're not there. Jan > 15. feb. 2021 kl. 15:17 skrev Ishan Chattopadhyaya > <ichattopadhy...@gmail.com>: > > Hoss, > One important reason why separate repo for solr-extras is a good idea, as > opposed to conrib modules, is that separate repo can be used to test against > many Solr versions. Imagine a component that works across Solr versions 6x > through 9x from day one. I can't imagine such a component being part of the > lucene-solr repo itself. > > Also, today, contrib modules are shipped with Solr, which we don't want for > new things we might want to build. > > On Mon, Jan 25, 2021 at 4:25 PM Ishan Chattopadhyaya > <ichattopadhy...@gmail.com <mailto:ichattopadhy...@gmail.com>> wrote: > I haven't been able to follow up on creation of the extras repo, but more > importantly I wanted to respond to Hoss. I'm out on an emergency for a week > or so, shall resume then. If there's a decision on this until then, I shall > accept it. > > On Mon, 25 Jan, 2021, 9:04 am Jason Gerlowski, <gerlowsk...@gmail.com > <mailto:gerlowsk...@gmail.com>> wrote: > Tentative +1 to Hoss' questions. I agree with his summary of the > potential risks here, and I share his ignorance of the perceived > benefits. > > (I thought for a time that this was driven by interest in having > release cadences independent from Solr-core releases. I'm all for > that goal, but if that's the motivation I'm not sure what the obstacle > is to doing that with a single repo - all build systems these days > support versioning and releasing modules independent of one another. > But maybe that was never a driving factor here.) > > I know there have been a lot of discussions about this, and I know the > repo has already been created. So maybe it's too late to object even > if I wanted to, which I'm not sure I do. But can someone that > understands the motivation please summarize what multiple-repos gets > us over a single repo that outweighs the "cons" that Hoss mentioned? > > Jason > > On Thu, Jan 14, 2021 at 12:34 PM Chris Hostetter > <hossman_luc...@fucit.org <mailto:hossman_luc...@fucit.org>> wrote: > > > > > > : As we discussed over the last few months, there seems a need to move > > : non-core pieces away from the Solr core module. The contribs are presently > > : a good place, but it makes sense to have a separate git repository hosting > > : such modules. Some candidates that come to mind are the present day > > contrib > > > > can you explain why it makes sense to have a separate git repo for these > > things? > > > > I can think of lots of reasons why it makes sense to have a single > > repo for all things solr (unified CI that quickly identifies if core > > changes break "first order" plugins, shared feature branches & monotomic > > commits of code that affects APIs and impls of those APIs, etc...) but > > I've yet to see any concrete specifics of why multiple git repos are > > "better" then just having distinct sub-projects (with distinct artifacts) > > in the same repo other then "it makes sense" > > > > why does it make sense? > > > > why can't the ideas of "solr-sandbox" and "solr-extras" just be > > directories in the "solr repo" ? ... what value is gained by making them > > new repos? > > > > > > -Hoss > > http://www.lucidworks.com/ <http://www.lucidworks.com/> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > <mailto:dev-unsubscr...@lucene.apache.org> > > For additional commands, e-mail: dev-h...@lucene.apache.org > > <mailto:dev-h...@lucene.apache.org> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > <mailto:dev-unsubscr...@lucene.apache.org> > For additional commands, e-mail: dev-h...@lucene.apache.org > <mailto:dev-h...@lucene.apache.org> >
