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 :-(
