I am a bit confused -- if Lucene was to become a sub module of Solr, are we essentially forking Lucene?
I am in agreement with Ilan and Houston -- Solr should be depending on Lucene only as a dependency. On Tue, 4 May 2021, 19:52 Noble Paul, <noble.p...@gmail.com> wrote: > @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 >
