Improved Helm chart versioning practices

[rptaylor]

What would you like to be cleaned:

Improve helm chart versioning to follow best practices. The CI that is used to produce Helm charts appears to overwrite the chart version with the appVersion, meaning that the two are always the same.

Why is this needed:

See discussion: #3925 (comment)

The comment #3925 (comment) illustrates some issues that could be improved.

Going forward I would suggest using both chart version and appVersion, and they should necessarily diverge over time: let the chart version be incremented on any/every chart update (including a new kueue version, i.e. appVersion), while the appVersion should only change when the default value of the kueue version changes. There is a reason that two kinds of versions exist and it is best practice to use both as intended.

Aside from that, personally I found it a bit counterintuitive/confusing when trying to install the kueue chart - it seemed odd that I needed to use the appVersion when retrieving the OCI chart, when normally the chart version is used (which appeared to be 0.1.0 based on https://github.com/kubernetes-sigs/kueue/blob/main/charts/kueue/Chart.yaml but evidently that is not the case; afterwards I realized the chart version must be set equal to the appVersion when CI publishes the chart).

[mimowo]

Thank you for opening the issue, the chart versioning in Kueue is confusing indeed.

In particular, the version field seems to be totally ignored even though the comment suggests to update it based on the semantic versioning. Instead, the values is ignored and set to appVersion- I'm yet not clear which code specifically does the overwrite, but it looks like that. do you know @tenzen-y ?

However, I'm not yet clear about the practical issues from the user perspective. We never update the helm charts for a specific version, so v0.10.0 will always be the same chart. Bugfixes are released in point releases. The published charts for the daily builds of the charts also don't conflict as the version is very specific, eg. v20241112-v0.10.0-devel-31-g43b73747.

So, it might be we should just update the comment to indicate the "version" field is set by the CI process (and best if we also indicate where and which step for transparency).

[rptaylor]

Okay thanks for clarifying and elaborating. Based on further discussion in #3925 (comment) it is again not as bad as I first thought. ><

If version and appVersion are both used to separately represent the chart and app version, it would allow the chart and kueue release process to be decoupled; new charts could be released more rapidly than the release cycle of the kueue code/image. The daily chart builds could be another way to address that though. It would be useful to have some notes/docs about how/where to find the daily builds, possibly also in Chart.yaml as a helpful pointer. With OCI charts, unlike a helm repo, AFAICT you can't browse available chart versions.
Anyway thanks!

[zargor]

It is still misleading having chart version 0.1.0 and app version v0.10.1, while actually those versions are identical, both are v0.10.1

Also would be great to release new chart deprecating rbac proxy. As noticed there is already a commit covering that.
81b90cd

[mimowo]

i agree the field comment is misleading and I would welcome a PR to improve it, or just drop the version field entirely. im not sure we have any user facing issue due at the moment.