Hi @lucacome. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

I think this needs some discussion:

• we currently control updates to minor version releases of Go; especially as we reach release milestones, we don't want the minor version to change automatically between test and release. Using the go.mod file approach doesn't allow us to do this.
• we are currently still supporting building 1.7 with Go 1.18.x; we need to discuss and agree to drop that support before we can adopt these changes (or more specifically, update the k8s vendoring to code that can only build with Go 1.19+)

Regardless, I think we want to support the last 2 versions of Go, so even when Go 1.19 is superseded by Go 1.20, I believe we will still want our matrix definition of versions in the GitHub actions CI workflow, so I don't think the go.mod based version definition in CI is the right model for us.

Of course, this is just my opinion. Need the rest of @containerd/committers to offer their opinions.

Also, the name of the PR is confusing given the existence of Go 1.19 used everywhere in our CI and release process :) Maybe you mean "Remove Go 1.18 support"

close by #8109

@fuweid that doesn’t really bump the version…

@lucacome sorry for the mistake. :( Please feel free to file other pr to upgrade the version in go.mod. Sorry for any inconvenience!

Already updated in #8103
281f89a