-
Notifications
You must be signed in to change notification settings - Fork 363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adhere to semver #554
Comments
Our chart would release for two cases:
What about we make a rule like below:
Such as if Velero release V1.13.1 If we have one urgent breaking change, it will break the semver rule. we could add a table in the README to record the relationship between chart versions and Velero versions. |
Any ideas about it? @jenting @reasonerjt @ywk253100 |
But, why? Why not just follow semver? 🤔 A velero patch update is a patch update for the chart, just because there is no lesser level of version. |
@cwrau Thanks for your response. The main purpose of making the semver version rules is we want each Velero release version to have a range of independent chart versions and avoid conflicts in chart versions. For Velero, it will release a version in the normal development cycle like v1.13.0 If our chart doesn't have a clear rule related to the Velero version, it would make the chart version disordered and even conflict. |
Now I've updated one new idea: we should have two aspects that need to be considered.
Branch controlFor the branch control, we could have one new branch when Velero releases one new major version: For Velero minior release, we could still use the current branch but tag one label Velero 1.13.1, we use the branch named for the chart version, we could follow the rules in the next section. If we have the branch control, we could release an older helm chart with the older branch. For version control:Our chart would release for two cases:
What about we make a rule like below:
|
Oh wow, you plan on having multiple Helm Chart "strains"? So multiple concurrent chart "versions"? That of course complicates things, a lot Why not just go forward with velero and follow the standard semver? 🤔 I would even go so far as to say that staying on an older version of velero is a special case and just updating is the normal way, so having no real way to update older velero versions is not a problem for the normal user. This is of course easier if velero itself also follows semver, but if it doesn't, you either have to carefully read each and every release changelog or also open an issue "upstream" so they use semver as well 😅 Which looks like it's the case, as you say To summarise, if this chart isn't going to follow real semver, then there is no big gain in changing the versioning concept, as with the new concept I still can only auto-update patch versions, which won't update velero to the next minor version 😅 |
yes Maybe if we want to support concurrent chart "versions", the idea I mentioned maybe work. |
@cwrau Would you mind giving a more concrete example? Are you suggesting that the chart should bump up the major version in #549 ? I would rather suggest that we should have an easier way to map between the version of |
Then, as I said, I see two ways to handle this in a semver way, either the one bumping the velero version inspects the changelog and determines if there is a breaking change or we open an issue upstream so they change their versioning to semver as well.
Definitely, that way the user can see at a glance that there is a breaking change in that version, and, conversely, see that other versions are safe to upgrade to, as there is no breaking change in there.
If you really want to support multiple concurrent versions, I guess one could still use the major version for tracking the breaking upstream velero and follow semver. You'd just have to never do anything breaking in the old versions 🤔 That would be restricting, but I guess that should work. And major reworks, or anything breaking really, would only happen in the latest version and bump the major version. |
@cwrau Thanks for your advice. So following semver rule is the prerequisite, also we want to support multiple concurrent versions. If we want to meet the conditions above, the breaking changes of There is no strong correlation between Chart versions and Velero versions as we still could get the Velero version through Semantic versioning is summarised below:
So :
Another thing we need to consider is cutting the branch when the Velero minor version is released, the details we could follow the rules I mentioned about |
@jenting Do you have any idea about it? |
@cwrau I think a major sticking point that you're overseeing is the fact that Velero itself doesn't adhere to SemVer... so if the helm chart adheres to it, there will be major updates for every minor velero release. In that sense @qiuming-best's last response seems to cover that in the proposed versioning scheme. |
I didn't miss it, I would say it's not a problem? 🤷♂️ Just because they don't adhere to it doesn't mean we can't make the live of our users easier by adhering to it. 🤔 |
@cwrau fair enough, just thought it would bare highlighting as it does imply that the helm chart's major version would change fairly often. tbc I'm a fan of having the helmchart adhere to semver ;) |
@cwrau @siegenthalerroger please take a look at the PR that I submitted, especially the instruction doc. Thanks |
Any news on this? Looking into the PR, some users are waiting to install a newer version with fixes they need (me, too) for quite a long time. Perhaps stay with the current versioning and build the chart the "old" way until the decision about semver is made? |
@TTRCmedia not sure what you're waiting for tbh, there's not going to be any retroactive changes anyway. None of the breaking changes have been disturbing enough to warrant waiting with the deployment of required fixes. |
Oh sorry, I did not see the last comment before mine and the linked PR. My comment was about this PR to build the chart for 1.13.1, as that version includes the fix for vmware-tanzu/velero#7445 we are waiting for. |
Ah, no problem. You can manually bump the velero version for patches if you need to (I have for my org) by overriding the value. You have to bump the plugin versions manually anyway so it's never bothered me if I have a pressing concern.
|
Sure, you could do that, but then Helm would report wrong APP VERSION.
|
Describe the problem/challenge you have
Currently the velero helm chart kinda randomly decides which part of the version gets bumped when a change is merged, see #549 (comment). This means that every user has to look at every little (patch/minor) release to see if something broke for them.
Describe the solution you'd like
Adhere to semver.
Anything else you would like to add:
This helps users judge releases just by their version number and use tools to auto-update or to automatically create small PRs to update versions.
The text was updated successfully, but these errors were encountered: