Imagine a component that wants to have its own release cadence. Say, a 1.x line of the component that supports certain features (across Solr 6x to 9x) and 2.x line that supports certain other features (which are a big upgrade from previous 1.x). A Solr UI can be a good example, where say 1.x uses React and 2.x uses AngularJS. Shoving such a component into lucene-solr repo makes no sense, given its branching strategy is based on master / branch_8x (and later it will become branch_9x and master).
On Tue, Feb 16, 2021 at 5:19 PM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > > 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. > > It'll be great to test contrib's on multiple Solr versions, but I > can't see any blockers for this that are same-repo specific. Can you > elaborate on what makes this tricky in a same-repo setup? AFAICT you > can set up multiple gradle test tasks that rely on different > solr-test-framework versions and run tests that way - regardless of > where the code lives. (Or alternatively, docker images for various > Solr versions as David suggested.) > > I think Jan's got a good point about how do-able it'll be in practice > to have plugins support multiple major release versions. That said > though, a lot of these questions (docker tests vs otherwise, cross > major-version plugins?) will likely sort themselves out when it comes > time to implement. > > On Tue, Feb 16, 2021 at 12:21 AM David Smiley <dsmi...@apache.org> wrote: > > > > I think embracing Docker is how we can identify if a plugin works in > multiple versions of Solr. The setup of such a test would start Solr via > Docker and install the plugin into a Solr server using the package > manager. The test code itself would interact with Solr purely via > SolrClient. This would be an integration / smoke level test for the > plugin. I test my plugins at work similar to this way at a "smoke" level, > which follows "integration". What's cool is that we can take the very same > test and either have it run via an embedded Solr (which we call an > integration test) or a remote'ed Solr (run via Docker, which we call our > "smoke" test). Naturally, if a test makes assumptions that only work in > embedded, then it won't run in smoke mode, so we have annotations to > categorize the tests. I'd like to work on some JUnit "Rule" for Solr, > similar to what I have at work (and have done in the past) -- > https://issues.apache.org/jira/browse/SOLR-11872 > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Mon, Feb 15, 2021 at 9:17 AM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> > >> 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> 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> > 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> 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/ > >>>> > > >>>> > > --------------------------------------------------------------------- > >>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>>> > For additional commands, e-mail: dev-h...@lucene.apache.org > >>>> > > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
