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
