We moved one Go variable and every copy of our new CLI was told to upgrade

Description and use

Moving the version variable in a Go project caused all released binaries to report an incorrect version and be rejected by the API gateway. The fix involved updating the linker flag and validating the version before signing.

Problem

A release workflow misconfigured a linker flag, causing all published binaries to report an incorrect version and be rejected by the API gateway.

Outcome

All published binaries now report the correct semantic version, partners no longer receive false upgrade prompts, and the API gateway accepts valid requests.

Workflow

• 1. Update release workflow to use -X internal/buildinfo.version instead of -X main.version.
• 2. Add a pre‑sign check that runs the built binary’s version command and compares output to the git tag.
• 3. Sign and publish the binary only if the check passes.
• 4. Ensure the API gateway parses the version header correctly and does not downgrade unparseable values.

Evidence

The release workflow builds it with go build and an ldflags option, -X main.version followed by the tag, which tells the Go linker to set the string variable version in package main to that value.

Source

In 2.7.0 a tidy up moved build information out of main into a package of its own, internal/buildinfo, and the variable went with it.

Source

The Go linker does not treat an -X naming a symbol that does not exist as an error, or even a warning. It ignores it.

Source

The release workflow now runs the built binary with its version command and fails unless the output matches the tag, character for character, before anything is signed.

Source