As with any dependency on any project, you update the dependency project first then consume the updated dependency in Solr.
If the idea is to be able to modify Lucene and Solr in parallel, then the project split is counterproductive. >From the Solr perspective, Lucene and Zookerper are really two “similar” dependencies and IMO we should think about them in that way. Ilan On Tue 4 May 2021 at 09:45, Noble Paul <noble.p...@gmail.com> wrote: > @Houston > > So, Are you suggesting we should not do that ? > > On Tue, May 4, 2021 at 2:35 PM Houston Putman <houstonput...@gmail.com> > wrote: > >> In the future we wont be able to “work on both at the same time”, once >> Lucene 9 is cut. Why not pull that bandaid now? >> >> On Mon, May 3, 2021 at 11:32 PM Noble Paul <noble.p...@gmail.com> wrote: >> >>> I'm still struggling to understand the workflow when I'm working on a >>> feature that spans lucene and solr. >>> >>> I'm yet to see an argument against sub-modules >>> >>> On Wed, Feb 17, 2021 at 3:18 AM Jason Gerlowski <gerlowsk...@gmail.com> >>> wrote: >>> >>>> > Shoving such a component into lucene-solr repo makes no sense, given >>>> its branching strategy is based on master / branch_8x >>>> >>>> I get how this could cause issues - I def hadn't thought much about >>>> multi-version support and branching. But I don't think moving plugins >>>> to a separate repo solves that problem for us. If our first class >>>> plugins are set up to have different release "lines" that don't line >>>> up with major Solr versions, it's only a matter of time before two of >>>> those plugins have branch requirements that conflict. Unless I'm >>>> missing something here? >>>> >>>> > I'd prefer that a module only leave our "contribs" area when the >>>> concerns/limitations become real. Doing it prematurely could lead to >>>> atrophy of the module.... >>>> >>>> +1 to David's comment. I def hadn't considered the branching-scheme >>>> issues that Ishan brought up in his last reply, and they seem like >>>> valid concerns to me. But the risk and the downsides of "atrophy" are >>>> serious enough that I'd vote to not risk them until this starts to >>>> cause us issues in practice. Even if, for now, that means we won't be >>>> able to build a single plugin jar that supports (e.g.) 3 major Solr >>>> versions. IMO that's a much smaller loss. >>>> >>>> On Tue, Feb 16, 2021 at 9:40 AM David Smiley <dsmi...@apache.org> >>>> wrote: >>>> > >>>> > On Tue, Feb 16, 2021 at 8:38 AM Eric Pugh < >>>> ep...@opensourceconnections.com> wrote: >>>> >> >>>> >> 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. >>>> > >>>> > >>>> > Thanks for the link to that Querqy PR. That is *very* similar to >>>> what I do at work (minus multi-version testing), and also similar to how I >>>> test multiple versions in one of my pet projects by using a CI build matrix >>>> of a configurable dependency. I didn't know Testcontainer.org has its own >>>> Solr module -- https://www.testcontainers.org/modules/solr/ but we >>>> implemented that ourselves; not hard. >>>> > >>>> >> >>>> >> 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, >>>> > >>>> > >>>> > I'd prefer that a module only leave our "contribs" area when the >>>> concerns/limitations become real. Doing it prematurely could lead to >>>> atrophy of the module.... >>>> > >>>> >> >>>> >> 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. >>>> > >>>> > >>>> > Agreed :-( >>>> > >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>>> >>> >>> -- >>> ----------------------------------------------------- >>> Noble Paul >>> >> > > -- > ----------------------------------------------------- > Noble Paul >
