> I would argue we've done a pretty good job at maintaining backwards > compat in the CRDs, which has added a lot of extra heavy lifting by > Houston at times.
Agreed, for sure. To be super clear - I'm not trying to imply blame or laxness or anything like that. I think it's been good judgement throughout, and I appreciate all of Houston's (and everyone's) work there. I just wanted to get a conversation going around v1 to see where everyone thinks we are stability-wise. Definitely didn't intend any slight or offense there! On Fri, Mar 4, 2022 at 11:50 AM Houston Putman <[email protected]> wrote: > > 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? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
