How can we help maintainers to keep a more frequent release cycle?

Description

Hi there folks, hope all is well on your side! We've been using this project for a while and thank the team for the great work!

However, like already mentioned in past issues, we've also been struggling with the lack of new releases, which force us to fork the images and Helm charts internally to keep patching for CVE's and adding some of the small fixes already reported.

We've noticed multiple PR's have already been sent for bumps and fixes (and in some cases already merged), but new releases are still not being published, and the last references I could find about plans for a new release are over a year old.

Please note this is not at all, a rant or anything like that -- just trying to reach out to check how can we help support maintainers to keep release cycles going in a more frequent basis?

Though we found a few forks in the wild, and even considered in our company to do the same internally, I believe as most folks mentioned in different issues, a better approach would be keeping the project going forward. But start sending PR's would only make sense if maintainers confirm there are still plans for future releases, or if is there openness for new volunteers to step-in to help publishing new releases.

Again, thanks for the great work!

Importance

Blocker: Docker images are lacking updates for Linux, Java, and Zookeeper itself, which blocks us from using the operator in our production environments, where high severity CVE's are a no go, without maintaining internal forks.

Location

This affects the Docker image for Zookeeper, the operator image and dependencies itself and the Helm charts, as referenced in different issues, such as:

Suggestions for an improvement

Update the operator tooling, such as Kustomize, Controllergen and Kubebuilder itself -- as the project fails to build locally with the existing versions and multiple fixes have already been made on these to
Upgrade Go from 1.21 to 1.22+ along with the project's dependencies, as multiple high severity CVE's are easily updated with this bump -- I've performed tests locally, and the only code changes that were needed were small adjusts regarding metrics, as per below all vulnerabilities can be fixed with just this update:

trivy image --ignore-unfixed docker.io/pravega/zookeeper-operator:0.2.15-10-dirty  --skip-update --offline-scan
2024/10/01 08:03:44 WARN '--skip-update' is deprecated. Use '--skip-db-update' instead.
2024-10-01T08:03:44+01:00       INFO    [vuln] Vulnerability scanning is enabled
2024-10-01T08:03:44+01:00       INFO    [secret] Secret scanning is enabled
2024-10-01T08:03:44+01:00       INFO    [secret] If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2024-10-01T08:03:44+01:00       INFO    [secret] Please see also https://aquasecurity.github.io/trivy/v0.54/docs/scanner/secret#recommendation for faster secret detection
2024-10-01T08:03:44+01:00       INFO    Detected OS     family="debian" version="11.10"
2024-10-01T08:03:44+01:00       INFO    [debian] Detecting vulnerabilities...   os_version="11" pkg_num=3
2024-10-01T08:03:44+01:00       INFO    Number of language-specific files       num=1
2024-10-01T08:03:44+01:00       INFO    [gobinary] Detecting vulnerabilities...

docker.io/pravega/zookeeper-operator:0.2.15-10-dirty (debian 11.10)

Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

The same applies for the Zookeeper image itself, we already been keeping a fork of it internally in our company without any high severity CVE's as well, and would gladly contribute sending a PR with the required changes.
Default metrics are not being exposed, though https://github.com/pravega/zookeeper-operator/pull/582 has provided a way to workaround the issue, the changes were not yet published as a new release since last year.
Other security issues such as https://github.com/pravega/zookeeper-operator/issues/538 and https://github.com/pravega/zookeeper-operator/issues/562 can be easily fixed with small changes to the charts, just like some improvements can also be made to reduce some of the cluster level permissions, as mentioned in https://github.com/pravega/zookeeper-operator/issues/611
Using private registries for the Zookeeper cluster is also a bit convoluted, as mentioned in https://github.com/pravega/zookeeper-operator/issues/593, as setting the imagePullSecrets to the cluster resource itself has no effect, the only way we managed to work around the problem was by sharing the operator serviceAccount with the cluster, which requires a permissive access to be granted for it to work (cluster scope).

The main point of this issue is reaching out to maintainers to see how can we help, and to confirm if there are plans for new releases or perhaps allowing new contributors to step in to help keeping a more frequent release cycle.

Again, thanks for the great work!

pravega / zookeeper-operator