Thanks for bringing this up Jason, I think it's definitely something we need to plan for. I've also had people ask me personally if it's ok to use in Production, even though it's in "beta" state, so I think the concern is valid.
Mike we do have a Version compatibility matrix for both Solr and Kubernetes: https://apache.github.io/solr-operator/docs/upgrade-notes.html#version-compatibility-matrixes I think we are getting close to stability for the v1 API version, and a 1.0 release. However I think it might be worth it to require Solr 9x for that version, and thus wait until Solr 9.2 is out as Tim mentioned. There are a lot of improvements we can make when that happens. I've been keeping a running list here: https://github.com/apache/solr-operator/blob/main/dev-docs/changes-for-minimum-solr-version.md When we do the v1 API release we will also need to add multi-version support, so that users can use the v1beta1 and v1 CRDs interchangeably and have time to migrate. This won't be a small task, so we definitely have some time before we can release v1.0. I'm glad you mentioned documentation as well Tim, I definitely don't think 1.0 should be released until the Solr Operator documentation is included in the ref guide and has a bit of an overhaul. This shouldn't take as long as the multi-version support, but it's not a trivial task. Overall I would not be surprised if v0.6 and v0.7 are released before we get a 1.0, and we might want to keep development of v0.x alive if we only support Solr 9.0 in v1.0. But it's good to get the ball rolling and have a list of goals we want to accomplish in v1.0 - Houston On Fri, Mar 4, 2022 at 11:40 AM Mike Drob <[email protected]> wrote: > On Fri, Mar 4, 2022 at 9:43 AM Timothy Potter <[email protected]> > wrote: > >> Also, we should draw a hard line in the sand on which versions of Solr >> the 1.0 operator supports! It'll likely be one of the later 8.x >> versions. >> > > In addition to this, I think we will need to be aware of what versions of > Kubernetes each version of the operator will support. I know that k8s 1.22 > removed many deprecated APIs, but I don't recall if that required changes > to our operator. Would similarly scoped changes in the future require us to > go from 1.0 to 2.0 to 3.0? >
