> 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
