It's close but I don't think it is quite ready for 1.0. However, 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.
Mainly the compat breaks were due to removing features added early in the project that didn't work out. We're mostly past those issues now, which is why I think we're close, and most changes moving forward are going to be optional additions to the CRDs. Personally, I'd like to see more documented use cases on platforms like OpenShift and Azure Kubernetes. I actually doubt the v1beta1 label is stalling adoption all that much, I don't think this has been raised as a concern in the slack channel? Kubernetes itself has many "beta" API versions that are very much being adopted and used in production. 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. I'm thinking around 9.2 is probably the right time (not sure when that will be of course). I doubt many will deploy 9.0, so we may not get that much feedback on running Solr 9.x until 9.1. Having 1.0 come out around 9.2 gives us some time to get ready after seeing some deployments of 9.1. Tim On Fri, Mar 4, 2022 at 8:05 AM Jason Gerlowski <[email protected]> wrote: > > Hey all, > > Houston's email thread from earlier this week got me thinking: is > solr-operator stable enough and ready for a 1.0 release? > > Deferring the 1.0 release (and keeping our Kubernetes CRDs versioned > at "v1beta1") has been convenient for development up to this point, as > changes can be made without strict backcompat guarantees. But that > flexibility might give potential users pause in adopting the operator > if they need something more stable. > > Have there been any past discussions about doing our first major > release of the operator? Are there any blockers standing in the way > of a 1.0 release? Anyone have opinions on whether we're ready vs > needing more time to stabilize? > > Best, > > Jason > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
