Release controller v1.12.0-beta.0 & chart v4.12.0-beta.0.

[Gacko]

/triage accepted
/kind feature
/priority important-soon
/cc @strongjz @rikatz @cpanato

[tao12345666333]

Due to the significant number of break changes involved, I suggest upgrading the Helm chart version to v5.x.

[Gacko]

Due to the significant number of break changes involved, I suggest upgrading the Helm chart version to v5.x.

Hm, but then I'd also bump the controller version to 2.x.x and we decided not to do this. Also the chart is not really introducing breaking changes, it's rather the controller introducing them.

[tao12345666333]

However, some deployment tools will automatically deploy minor versions of helm charts. I'm worried that this will have some unintended consequences.

[tao12345666333]

However, some deployment tools will automatically deploy minor versions of helm charts. I'm worried that this will have some unintended consequences.

[Gacko]

Still the breaking change IMHO is not in the chart itself. Actually the chart is just dropping PSP, which could be breaking, but this has been deprecated since Kubernetes v1.25, so you shouldn't even use it anymore as long as you're not running Kubernetes < v1.25, for which we already dropped support.

I get, that we are shipping breaking changes in the controller, but we already did that in the past and didn't decide to bump the major version for 12 minor releases now.

Of course we can re-evaluate this in future releases, but I'd like to keep controller and chart versioning in sync and not start the whole process from the beginning now. So would it be possible to go on with the current version number and get this merged asap? 🙂

Keep in mind: This is still just a beta and if everything goes wrong, we'll just stop the beta phase and directly do a v2.0.0 from main, so kill the release v1.12 train before it even started.

Which is another reason to me for why it shouldn't be an issue: Automatically updating to a beta version... #yoloengineering. 😬

[Gacko]

Of course we can re-evaluate this in future releases, but I'd like to keep controller and chart versioning in sync [...].

This means: The chart ships the controller. So bumping the chart by major while only bumping the minor of the controller does not make sense to me, if the change in fact is in the controller. If the breaking change is directly in the chart, I totally get you and it would make sense to bump the major of the chart.

We have the controller and the chart independent so we could - theoretically - release the chart independently from the controller. In reality we never do this and just always also release a new version of the controller and include this in the chart.

[strongjz]

/lgtm
/approved

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Gacko, strongjz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Gacko,strongjz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Gacko]

/hold

[k8s-ci-robot]

New changes are detected. LGTM label has been removed.