Very good question.
Currently we "support" all recent versions of Solr, meaning 7 & 8. This doesn't mean that Solr 6 won't work, it just hasn't been thoroughly tested. We do eventually plan on limiting support to a range of Solr versions. I imagine that once Solr 9 is released, we will begin supporting 8+ on the next Solr Operator release. But we could explicitly call out support for 7.7.2+ starting with v0.4.0, if we so desire. We have been adding a few things to Solr, so that in the future the operator code can be less complex. We should compile a list so that when we are upgrading the minimum Solr version, we have an easy way to see the Solr Operator changes that should be made in response. I would say that you can add support for a feature that requires a newer version of Solr, it just has to be optional and turned off by default. The documentation in the CRD as well as the Solr Operator docs should plainly state the minimum Solr version needed for that feature. But that's my opinion, I would love to hear from others. - Houston On Mon, Aug 2, 2021 at 5:13 PM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > Hey all, > > Breaking out this thread from a side-comment on "Proposal to cut the > v0.4.0 release soon". > > Are we targeting particular Solr operator releases at particular Solr > versions (or ranges of Solr versions)? (If not, should we be?) > > The repo README calls out Kubernetes version compatibility but doesn't > speak to Solr compatibility that I saw. I imagine this isn't a huge > issue generally assuming Solr's docker image structure stays > relatively unchanged, but it does matter in some situations: e.g. if > the operator wanted to add a feature taking advantage of a Solr > feature only introduced in, say, 8.8. > > Best, > > Jason > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
