Toolchain

Upgrading Go in WSL or Linux is usually one archive extraction, but it is easy to hide an old compiler behind PATH or accidentally accept a dependency-file rewrite while testing it. The compiler installation and the module files are separate concerns. Treat them that way and the upgrade is straightforward to test and easy to roll back. I first select the new compiler, run an existing project’s tests and build, and inspect go.mod and go.sum before deciding whether either file should change. A compiler upgrade does not, by itself, require a new module language version or a dependency cleanup. ...

Upgrading Go on a Windows workstation should be a small change, but it can become confusing when two things change at once. The installed Go compiler changes first. Then a command such as go mod tidy may propose changes to go.mod and go.sum. Those are related, but they are not the same job. I keep the first upgrade test deliberately narrow: install or select the new compiler, run the existing project’s tests and build, and inspect the module files before accepting any change. That gives a useful answer when a project fails: is this a compiler/toolchain problem, or did the dependency graph change? ...