Testing across multiple versions is always very difficult ;-). I recently saw this very interesting approach to using our Dockerized Solr’s to test a component against a number of previous versions of Solr. https://github.com/querqy/querqy/pull/147. I’m hopeful it could be a model for other packages to adopt.
Trying to maintain across multiple versions is kind of a Sisyphean task, and I don’t think plays to open source communities strengths. It’s hard enough to keep all components of Solr up to date with the latest Lucene and the latest Solr…. (Try out wt=xlsx Response Writer, it’s currently broken on master) . Reminds me of the Apache Gump project ;-) If something is really going to be backcompatible across certain versions, then maybe having it’s own repo makes sense, but I suspect it means those components may go stale…. Look at DIH and Velocity components that are moved over to their own repos, both are getting stale, and I’d argue it’s because they don’t live in the main project where all of us have oversight and easy access. > On Feb 16, 2021, at 7:44 AM, Ishan Chattopadhyaya <ichattopadhy...@gmail.com> > wrote: > > 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 > <mailto: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 > <mailto: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 > > <https://issues.apache.org/jira/browse/SOLR-11872> > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > <http://www.linkedin.com/in/davidwsmiley> > > > > > > On Mon, Feb 15, 2021 at 9:17 AM Ishan Chattopadhyaya > > <ichattopadhy...@gmail.com <mailto: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 <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> > >>>> > > --------------------------------------------------------------------- > 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> > _______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
