After a dependency upgrade, go build fails saying a module requires go >= 1.24 while CI runs Go 1.22 — why, and what are your options?

## Whose version requirement is this, exactly? The error names a module and a version, and the first job is to work out which module — because there are two independent ways a build acquires a floor of `go 1.24`. ### Source 1: a dependency's own go line Every module records its own go directive, and every module whose packages are compiled into your build has to be compilable by the release doing the build. So when a dependency's maintainer raises their go line to 1.24 and you upgrade to that version, your build now needs a Go 1.24 or newer install, even though your own go.mod is untouched. This is the mechanism people find surprising: you did not change a version, and yet your version floor moved. Importantly, this does **not** mean your module must declare `go 1.24` too. Language versions are per module: your files can keep compiling at 1.21 while the dependency's compile at 1.24. Only the installed release has to satisfy the maximum across the build. ### Source 2: your own go line, quietly raised The go command keeps go.mod consistent with what your requirements need, so an upgrade command that pulls in a module with a higher go line can rewrite your own go directive as part of the same operation. That change is in the diff, and reviewing the go.mod diff alongside the go.sum churn is the habit that turns this into a five-minute diagnosis instead of an afternoon. ### Diagnosing it 1. `git diff go.mod go.sum` — did the go directive move? Which requirement is new or upgraded? 2. `go list -m -f '{{.Path}} {{.GoVersion}}' all` — prints the recorded go line for every module in the build list, so the 1.24 offender is a scan away. 3. `go version` — confirm what the CI image is actually running, which is frequently not what the README claims. ### The options, in the order most teams should consider them **Move CI forward.** Usually correct. Go supports each major release until two newer ones have shipped, so pinning several releases back means running something that no longer receives fixes. A version floor arriving from the ecosystem is the ecosystem telling you your image is old. Change it in one place, run the suite, done. **Step the dependency back.** Legitimate when the image genuinely cannot move this week — a platform migration in flight, a certified base image, a release freeze. `go get [email protected]` selects the last version whose go line you can satisfy; re-run the build list check to confirm nothing else in the graph still demands 1.24, because a transitive requirement can hold the floor up on its own. Record why, with a date, or the pin becomes permanent by accident. **Drop or replace the dependency.** Worth considering when the dependency is small and the floor it imposes is disproportionate to what it does for you. **Lowering your own go line.** Almost always the wrong reflex, and it does not help: `go mod tidy -go=1.22` sets *your* language version, but it cannot lower the dependency's go line, so the build still needs a 1.24 install. This is the single most common wasted step on this failure. ### Making it a non-event next time - Pin the Go release in one place — the CI image definition — and treat raising it as a normal, scheduled change rather than an emergency. - Build the module on the oldest release you claim to support, in CI, on every change. Otherwise "we support Go 1.22" is a belief rather than a fact, and you discover it is false at the worst moment. - Review go.mod diffs like code. The go directive moving is a compatibility event for anyone who consumes your module, not a formatting change. - Publish the release you support so your own consumers can plan; a floor that moves without notice is the same problem one level down.