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 >
