Update go 1.22.7

[koba1t]

fix #5762

[k8s-ci-robot]

This PR has multiple commits, and the default merge method is: merge.
You can request commits to be squashed using the label: tide/merge-method-squash

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-sigs/prow repository.

[koba1t]

@varshaprasad96
Please type the retest command after kubernetes/test-infra#33478 is merged.

[varshaprasad96]

/retest

[varshaprasad96]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: koba1t, varshaprasad96

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 [koba1t,varshaprasad96]

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

[sbueringer]

@koba1t Was the minimum go version in the go.mod file intentionally bumped to 1.22.7? (instead of just 1.22.0)

We have a dependency to kyaml and the minimum go version in the kyaml go.mod file would now force us to also require 1.22.7 as min version (which I would prefer to avoid if possible, as it in turn forces everyone that uses our module also to use >= 1.22.7)

(xref: kubernetes-sigs/cluster-api-provider-vsphere#3222 (comment))

[koba1t]

@sbueringer

Sorry, I just wanted to use go >= 1.22.0.
However, I feel that it is hard to downgrade the golang version of this project.

If it is acceptable, can you wait to upgrade kyaml until kubernetes-sigs/cluster-api-provider-vsphere is upgraded to go 1.23?

[sbueringer]

Sorry, I just wanted to use go >= 1.22.0.

No worries.

If it is acceptable, can you wait to upgrade kyaml until kubernetes-sigs/cluster-api-provider-vsphere is upgraded to go 1.23?

Talked to @chrischdi. We're fine, we have ways to work around it.

However, I feel that it is hard to downgrade the golang version of this project.

For us it's okay to keep it as is. Just one note for the future. There is a difference between the Go version that is used to compile a module and the minimium go version ("go 1.22.7") defined in the go.mod file. The latter forces everyone that imports the module to:

• also require a minimum go version of >= 1.22.7
• compile with at least Go 1.22.7

This affects everyone who has a transitive dependency on a module.

E.g. controller-runtime chose because of that to only require 1.22.0 in their go module: https://github.com/kubernetes-sigs/controller-runtime/blob/v0.18.5/go.mod

So overall I would just recommend going forward to use .0 versions in the go.mod file. You can (and should) still use a higher Go patch version for running unit tests, compiling binaries etc.

[chrischdi]

Note: For fixing the linked issue it should have been enough to bump the go version used for compiling and keep the go 1.21. That would even be cherry-pickable to branches for patch releases.

(Edit:)For fixing those issues it would still have been

Still okay I think to bump the directive to e.g. go 1.22.0 for a next minor release.