-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
📖 backport policy: Add go version bumps #7983
📖 backport policy: Add go version bumps #7983
Conversation
Signed-off-by: Stefan Büringer buringerst@vmware.com
cc @fabriziopandini @CecileRobertMichon @vincepri @enxebre |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
Seems reasonable to leave the conditions for this up to a case-by-case basis - especially depending on go version change impact, and how long the release is going to stay supported i.e. 2 months vs 2 days.
LGTM label has been added. Git tree hash: 41e5bbbdeddf416733ce4ddc17192d43f720ae95
|
Yup. I think we can see how it goes the first few times. It might depend on the exact changes in Go, but I think in almost all cases it shouldn't actually affect folks importing Cluster API when we only bump the version we compile with (it should not be strictly necessary to bump the version in go.mod, xref: #7974 (comment)). The only reason to bump the go.mod version would be to force consumers to compile with a newer Go minor version (e.g. to enforce that they pick up CVE fixes), although we can't enforce a specific patch version that way. But we can discuss and decide this when we get there. Bumping the Go version we compile with might have impact on folks using our published images though. For example changes in garbage collector behavior etc., like mentioned in the upstream mail:
|
@@ -169,6 +170,17 @@ This can be done by: | |||
2. If nobody is working on an issue in the milestone, drop it from the milestone. | |||
3. Ensuring we have a plan to get `release-blocking` issues implemented in time. | |||
|
|||
#### [Continuously] Bump the Go version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is primarily to keep the patch version up to date, right? If so, can we make that explicit that this item is only to update the patch version and not the minor version.
The minor version is updated during Kubernetes bump and not here, isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In most cases patch
Sometimes
Note: If the Go minor version of one of our supported branches goes out of supported, we should consider bumping
to a newer Go minor version according to our backport policy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kubernetes bump never bumps the go version on release branches as that part of the work is only done on main
/lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vincepri 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:
Approvers can indicate their approval by writing |
/cherry-pick release-1.3 |
@sbueringer: new pull request created: #8115 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Signed-off-by: Stefan Büringer buringerst@vmware.com
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):For context, please see #7974