Automation: bump patch version by default

[fabriziosestito]

Is your feature request related to a problem?

The Helm chart release automation bumps the charts by a minor version. Since in the most common scenario, we bump the container images version, we could instead default to a patch bump. If the Helm chart was changed (values added/removed, configuration changes, etc..) we will need to bump the versions manually.

Solution you'd like

No response

Alternatives you've considered

No response

Anything else?

No response

[viccuad]

The chart version informs about the features and compatibility of the chart WRT to helm upgrade. With that in mind, I believe:

• A new Kubewarden stack release should be a version minor bump.
• A breaking change on helm upgrade is a version major bump.
• A fix on the charts only (not necessarily with changes to the images, or other parts the Kubewarden stack) is a version patch bump.

This way, as a Kubernetes operator, one can know of the disruptiveness of the update by looking at the bump of version, and the extent of the features by looking at the bump of appVersion. This should be consistent with the RFC.

We could add an updatecli rule that diffs the previous version values.yaml against the proposed, and if they aren't mergeable, propose a major bump of the version. Or better, provide full schema of the values.yaml, and reason with that.

[flavio]

Closing, we've just agreed it's fine to bump the minor version