HoustonPutman commented on issue #563: URL: https://github.com/apache/solr-operator/issues/563#issuecomment-1527750023
Yes the Solr Operator is production ready, and has been used in production by multiple large companies. (Hard to actually get a sense for this. We hear from people as well as see people giving conference talks.) In a release or two, we will likely get a v1.0.0 release. The delay for this mostly lies in the expectations from Kubernetes in upgrading a CRD's version from `v1beta1` to `v1`. I would love for it to happen, but it requires a fair amount of code to achieve. It's much harder than just changing the version in the repo and saying "We are officially v1". And while we have contributors, there's not a lot of extra bandwidth to do a big project with minimal "impact" to actual capabilities. > while we do not anticipate changing the API in backwards-incompatible ways there is no such guarantee yet. This is somewhat true, and you can see in the version upgrade notes, that fields are moved and changed in minor versions (e.g. between `v0.6.0` and `v0.7.0`). However, if you do a rolling upgrade from `v0.5.0` to `v0.6.0` to `v0.7.0`, you will see no issues for existing resources. The Solr Operator will make sure to change/move the fields in the existing resources. You will just need to make sure that your new resources use the new CRD fields. So as long as you are ok looking at the upgrade notes before actually doing an upgrade, and upgrading one minor version at a time, you should see no issues with backwards incompatibility. > Could you please clarify and detail the sentence on the project status? runtime stable, dev api not frozen, production ok, still many bugs or code is frozen testing phase etc? Production ok for sure. There are pretty comprehensive end-to-end tests, and unit tests. It's been around for a while and has almost a million docker image downloads. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
