@Ilan Ginzburg <ilans...@gmail.com> I don't think the project split is counter productive because we have lucene as a sub module. Solr does not use lucene like a simple library. It's an integral part of Solr
On Tue, May 4, 2021 at 10:02 PM Ilan Ginzburg <ilans...@gmail.com> wrote: > 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 >> > -- ----------------------------------------------------- Noble Paul
