Bump up golang to 1.22.0

[djdongjin]

Given golang 1.21 has been EOL, I think we can upgrade golang to 1.22.0 at least? (containerd uses 1.22.0, cri-o uses 1.23 in main branch.

[thaJeztah]

Was there a specific need to raise the minimum required version? Go modules use minimum versions selection; that includes the go versions, and for library modules should specify the absolute minimum that can be used. eg golang's x/sys and others still allow go1.18, because the did not require anything more current; https://github.com/golang/sys/blob/d4ac05dc8c4c953ec29cae3df56c0833f4010763/go.mod#L3

[djdongjin]

Hi @thaJeztah thanks for review and suggestion. (moved PR to draft for now since need to fix CI errors)

Was there a specific need to raise the minimum required version?

There is no required need for this go update. It's mainly to make our dependency upgrade easier. E.g., from my experiment, both google.golang.org/grpc and k8s.io/cri-api updates require go 1.22 at least. I probably can find a relatively new version for them that still only requires go 1.21.

That being said, I'm happy to change it back to go 1.21 and update those deps to the versions that only requires go 1.21. :)

and for library modules should specify the absolute minimum that can be used.

I assume we still want to keep the versions in plugins to be up-to-date (e.g., at least uses a non-EOL version if possible)? E.g., keep ./go.mod at minimum, and update ./plugins/*/go.mod relatively frequently?

Meanwhile, a few clarification questions on go/deps around containerd projects:

• For libraries, do we want to update go version if it's needed to update some major deps (e.g., k8s.io, otel, grpc, etc).
• Do we need to keep the library's dependency version in sync with containerd?

Thank you!

[samuelkarp]

For libraries, do we want to update go version if it's needed to update some major deps (e.g., k8s.io, otel, grpc, etc).

Roughly yes, though a couple thoughts on this:

• Distro packagers of containerd may be using older versions of Go that are unsupported upstream, but still maintained by the distro. This would be the policy for stable distributions like Debian and Fedora, for example. Bumping too aggressively makes it difficult for packagers to still support containerd.
• CI should cover in-support versions of Go
• We may want to bump anyway once a version becomes too old, though that's still a bit fuzzy. We could look at when popular distros like Debian and Fedora phase out a given Go version as an example.

Do we need to keep the library's dependency version in sync with containerd?

No, but we definitely should test it (in CI) at a version in sync with containerd.