-
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
📖 Bump go minor versions in release branches if they are out of support #9415
📖 Bump go minor versions in release branches if they are out of support #9415
Conversation
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.
/area documentation
/lgtm
I think this is essential so our supported code is using support Go versions.
/hold
(for more input)
LGTM label has been added. Git tree hash: 58efe56177b27ce28b34af0a5bc87fc457a19552
|
to bump to a newer Go minor version (e.g. to pick up CVE fixes). This could have impact on everyone importing Cluster API. | ||
- Changes to use the latest Go patch version. | ||
- Changes to bump the Go minor version, if the Go minor version of a supported branch goes out of support (e.g. to pick up bug and CVE fixes). | ||
This has no impact on folks importing Cluster API as we won't modify the version in `go.mod` and the version in the `Makefile` does not affect them. | ||
|
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.
Please note that the bump will be automatically visible in release notes through the Go bump PR
Signed-off-by: Stefan Büringer [email protected]
0aff5af
to
2c0a59c
Compare
I'll also bring it up in the office hours today |
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
LGTM label has been added. Git tree hash: c1a3190c944ef8dd7e48446b63fd2a3b387b1544
|
/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.
/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.
/lgtm
@sbueringer just for background, have we ever had to modify the actual code when bumping go versions? Deprecations and minor things like that are not a problem, I'm only concerned about behavior changes in the standard library, defaulting changes, etc.
I know upstream k/k has run into this a lot which made version bumps painful and hence it used to be avoided in patch releases. I believe they are (were) now leveraging GODEBUG
to battle this. I wonder if we need to care about this or if our codebase is "high level" enough (ha) that we might not be hit by the same issues. That said, 1.21 is supposed to handle this by default so even if this is an issue, it might only be until al our minor versions are using 1.21 or higher.
IIRC in the past 2 years we never had to make a change when we bumped Go. I think the difference is that interactions with CAPI controllers are very limited and they are also well covered by e2e tests. Basically we're communicating with the apiserver and the apiserver communicates with us. I think a major difference for Kubernetes is that the kube-apiserver is accessed by everyone. But I think if we didn't have to make any changes on main when bumping to a new Go minor version it should be fine to bump on release branches a few months later when the previous Go version goes out of support. |
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.
+1 from me
@sbueringer will keep this open for a week lazy consensus |
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.
Thanks for bringing up this topic!
As a follow-up, we could think of ways for surfacing go versions (go.mod, build) if they diverge in release notes and eventually in the book
/lgtm
One idea would be to simply make it part of the release notes. Just like we should surface a list with all our Go dependencies and their versions (like upstream k/k), we could do the same for the Go version(s). I think this would be more sustainable then adding a table somewhere which maps Cluster API minor+patch versions to Go compile & go.mod versions (I also think it's more realistic that folks find & look it up in the release notes vs. somewhere in our book) |
cc @kubernetes-sigs/cluster-api-release-team @furkatgofurov7 ^^ |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini 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 |
/hold cancel |
/cherry-pick release-1.5 for the book |
@sbueringer: new pull request created: #9470 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 [email protected]
What this PR does / why we need it:
I would like to propose to change our backport policy. tl;dr is:
The reason why I'm bringing this up is because Go 1.19 is out of support as of now but we still use it on the release-1.4 branch.
The idea would be to only bump the Go version we use to build our controller images. This means bumping the version in the Makefile, but not in go.mod (go.mod would break library consumers), similar to what Kubernetes is doing (they also don't bump the go.mod file after the minor release is out).
In my opinion it is absolutely safe to do so as our Makefile version doesn't affect anyone that consumes our go code / module.
Overall we're aligning to the way Kubernetes is handling this, for more context see: https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/3744-stay-on-supported-go-versions
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #7974