Bumping the Go toolchain version
The Go 1 compatibility promise is not a guarantee that major-version bumps of the toolchain will always be painless.
Integrate pre-releases of the next major version of Go early and often, ideally every beta and RC. Open a draft PR with the toolchain bumped to see how CI feels about it. Keep it up to date as new pre-releases are published. The earlier in the Go release cycle we can find issues with the new toolchain, the quicker we can report the issues upstream and the more likely they'll be addressed before the GA release.
What we tended to do in the past is to;
- Prepare changes needed for the Go update (if any) that already applied before the update itself
- This may include addressing issues caught by newer versions of linters
- Update the linter
- Update Go, and changes that must go together with the Go update
Most of the time we did the preparation steps in a separate PR, both for visibility, as well as make backporting those changes to release branch(es) non-ambiguous (including it in the same PR as the Go update could otherwise mean "this is a partial backport, with commits X Y and Z omitted").
In this approach;
- All changes leading up to the Go (and/or Linter) update would be tested in CI before updating Go itself; this allowed us to be sure those changes work with previous Go versions (thus could qualify for backporting if desired).
- The Go update PR itself would be an "epic" (have a checkbox list with changes) so that we can still keep track of things related to the update (FWIW; this is one reason I tend to backport individual Go updates (e.g. see https://github.com/moby/moby/pull/44990) - I track back all Go updates, and look if potentially other changes were not yet included in the branch. Having the individual commits in backports also helps correlate the changes with the main branch)
- At that point, the Go update itself is more of a "ceremony" (it would only have the Go version update and only changes that MUST go together with the update (breaking changes))