[velero] Adhere chart to semver

[qiuming-best]

Special notes for your reviewer:

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• DCO signed
• Chart Version bumped
• Variables are documented in the values.yaml or README.md
• Title of the PR starts with chart name (e.g. [velero])

Fix #554

• Add helm release instruction document.
• Modify release workflow, make any commit merged into main or velero-helm-charts-v* trigger helm chart release.
• Modify lint-test, trigger test if the current submit different from the target branch

[siegenthalerroger]

looks good to me :)

[jenting]

@qiuming-best Thank you for coordinate the topic and comes out the idea and documentation. I have another ideas on this one, please take a look of my comments.

[jenting]

Personally, I don't think the helm chart itself follows the semver because the Velero bumps minor version (functionality change) but the corresponding helm chart changes the major version (breaking changes).

We could consider maintains the velero helm chart and Velero itself with this format . This makes the helm chart follows the semver as well, also we can easily check the helm chart upstream Velero version.

[qiuming-best]

@jenting
I do not quite understand the format :
The upstream charts follow this versioning: 1.0.#+upX.Y.Z
Could you please give more details explanation?

Our main goal for this PR about versioning is to solve the conflicts in chart versions problem
Not sure the format you mentioned could avoid the conflicts in chart versions problem?

If it could avoid the conflicts, we also need to plan the helm chart version reasonably related format in 1.0.#+upX.Y.Z ?

[siegenthalerroger]

@jenting the reasoning behind the chart requiring a major bump for every minor velero bump is because velero itself doesn't follow semver. There are often changes in minor velero updates that require changes to be made to the deployment. To a certain extent the helm chart could catch these and make them non-breaking, however the decision here would be to forego that effort and just admit that the helm chart just "moves fast and breaks things" in a sense.

[siegenthalerroger]

Having looked at the rancher example, they actually have the same "ruleset" in a sense. The helm major version is always bumped for a minor rancher release (the 100.x.y examples), just with an additional +up....

Personally I don't think the additional +up is necessary, that's what the appVersion field in the Chart.yaml is for, and it's what we use to track the upstream version in our deployments.

[jenting]

What if the Velero bump the major release? How should we tackle in the Velero helm chart?

My thought was

• if the Velero bump patch/minor/major version, the helm chart itself should bump patch/minor/major version.
• if the helm chart itself have to fix/feature/breaking change, bump the helm chart version ..-. For example: current version is 6.1.0-v1.13.0
  • The helm chart bug fix would be 6.1.1-v1.13.0
  • The helm chart feature enhance would be 6.2.0-v1.13.0
  • The helm chart breaking change would be 7.0.0-v1.13.0
  • The velero bug fix would be 6.1.1-v1.13.1
  • The velero feature enhance would be 6.2.0-v1.14.0
  • The velero bbreaking change would be 7.0.0-v2.0.0

[siegenthalerroger]

To the first question: just do a major bump as you'd expect.

To your suggestion: While that sounds fine, the issue raised was that the helm chart can sometimes manage to update to new velero minor versions without a breaking change, but sometimes it does. IMO, while the originally suggested change veers on the safe side (always doing major bumps for minor velero updates, just incase they have a breaking change), you could cover it just by making sure it major bumps if a breaking change is required.

[jenting]

Understood.