This is wrong. In here there should be a minimally supported version, so unless you do want to drop go 1.17 support right now (which is probably not the right thing to do, since go 1.17 is fully supported and is probably most used version at the moment), I would advise against this change.

OTOH maybe I'm wrong #6709 (comment)

A go directive indicates that a module was written assuming the semantics of a given version of Go

I am not sure exactly what this means, but I guess that unless the code starts using Go 1.18 features, it should not say "go 1.18" in go.mod.

The Go team has been very ambiguous wishy-washy on this; the version does indicate the minimum version that's expected to be compatible, but they were not enforcing that (yet??), and started doing things like this in their own repositories (e.g. golang/sys@0981d60) - effectively disregarding their own recommendations to at least support latest+previous (even if the version in go mod is not enforced yet).

Changing the version does affect what versions can be used to manage modules though; i.e., running go mod tidy with go 1.17 will no longer produce the same result (which means that anyone working on this project must use go1.18).

For this one, I'm a bit on the fence; is there anything we gain from the removed lines in go.sum? (the change from <1.17 to 1.17 did bring the improved "indirect" dependencies, so was clearer on benefits)

If we do decide to change, we should also update the go.mod in the integration client (which still looks to be on 1.15);

One small benefit I can see (which is what led me to to make this change) is that it results in a less complicated go mod graph which brings two benefits:

1. Fewer false positives on security scanning tools
2. For downstream tools using the containerd library, a potentially smaller go mod vendor output

I think we can change this to go 1.18 as long as we build containerd against 1.17 on our CI. This will guaranty compatibility.