Thank you for initiating this discussion on the Druid Operator release strategy.
I strongly believe decoupling the release cycles and moving to a separate repository (apache/druid-operator) would be the most appropriate approach. The Druid Operator is fundamentally version-agnostic - a single operator version can deploy and manage multiple Druid versions from 16.0.0 through 25.0.0 and beyond. Its releases are driven by operator codebase changes, Helm chart updates, and Kubernetes dependency updates (controller-runtime, api-machinery) rather than Druid releases. The Kubernetes ecosystem has specific distribution requirements that differ from traditional Apache source releases. Users expect to deploy operators via Helm repositories using standard commands like helm repo add and helm install, and the operator requires published container images to function. Without these distribution mechanisms, even with code in the Apache Druid repository, the operator would be effectively unusable for the Kubernetes community who rely on Helm and container registries rather than source builds. I recommend moving the Druid Operator to its own repository after the initial merge, establishing independent VOTE procedures, and setting up proper Kubernetes distribution channels including a Helm repository and container registry. This separation would best serve both communities while respecting their different release requirements and distribution models. Could you clarify what the process is for requesting a separate Apache repository and whether this requires a VOTE? Also, does Apache have existing infrastructure for hosting Helm charts and container images that could be leveraged?
