@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
