📖 Bump go minor versions in release branches if they are out of support

[sbueringer]

Signed-off-by: Stefan Büringer buringerst@vmware.com

What this PR does / why we need it:
I would like to propose to change our backport policy. tl;dr is:

• On main: let's align to the Go minor version used by our k/k dependencies (Makefile + go.mod)
• On release-branches: let's bump the Go minor version used to build our controller images if the Go minor version goes out of support (only Makefile)

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

[killianmuldoon]

/area documentation

/lgtm
I think this is essential so our supported code is using support Go versions.

/hold
(for more input)

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 58efe56177b27ce28b34af0a5bc87fc457a19552

[sbueringer]

Please note that the bump will be automatically visible in release notes through the Go bump PR

[sbueringer]

I'll also bring it up in the office hours today

[cpanato]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: c1a3190c944ef8dd7e48446b63fd2a3b387b1544

[chrischdi]

/lgtm

[furkatgofurov7]

/lgtm

[g-gaston]

/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.

[sbueringer]

/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.

[elmiko]

+1 from me

[elmiko]

@sbueringer will keep this open for a week lazy consensus

[fabriziopandini]

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

[sbueringer]

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)

[sbueringer]

cc @kubernetes-sigs/cluster-api-release-team @furkatgofurov7 ^^

[fabriziopandini]

/approve

[k8s-ci-robot]

[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:

• OWNERS [fabriziopandini]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sbueringer]

/hold cancel

[sbueringer]

/cherry-pick release-1.5

for the book

[k8s-infra-cherrypick-robot]

@sbueringer: new pull request created: #9470

In response to this:

/cherry-pick release-1.5

for the book

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.