Skip to content

chore: make go.mod the single source of truth for the Go floor - #575

Merged
FumingPower3925 merged 1 commit into
mainfrom
chore/417-unify-go-floor
Sep 11, 2026
Merged

chore: make go.mod the single source of truth for the Go floor#575
FumingPower3925 merged 1 commit into
mainfrom
chore/417-unify-go-floor

Conversation

@FumingPower3925

Copy link
Copy Markdown
Contributor

Closes #417.

The minimum Go version was stated four ways and three were wrong. go.mod and all nine submodules say 1.27.0, and CI pins 1.27.0, against:

file claimed
README.md (x2) Go 1.26.4+
CONTRIBUTING.md Go 1.26.3+
test/autobahn/README.md Go 1.22+

The README one is the one that bites. It is what a user reads before their first build, and 1.26.4 cannot build a module whose go directive is 1.27.0.

Rather than correct three copies of a number that has already drifted twice, each site now states the current floor and points at the go directive as the source of truth, so the next bump has one place to change and the docs cannot silently fall behind it again.

CONTRIBUTING's parenthetical justified 1.26.3 by the stdlib CVEs govulncheck surfaced on 1.26.2. That rationale expired along with the floor it explained.

Stale version stamps

The issue lists four in v1.4.0 stamps. There are eight; the other four are in driver/postgres/rows.go, dsn.go and types_numeric.go. Each marks a limitation that is still true, dated to a release three minors back, so a reader cannot tell whether the limitation or the date is the stale part — which is the actual cost of a version stamp on a standing limitation. The limitations stay, the dates go.

Two are deliberately left alone because they are correct as history rather than stale:

  • SECURITY.md: "a Go 1.26.3 toolchain bump" — describes what v1.4.2 shipped.
  • driver/redis/state.go: "before v1.4.0" — dates a past optimisation, not a current limitation.

Docs and comments only; no code paths touched.

The minimum Go version was stated four ways and three of them were wrong.
go.mod and all nine submodules say 1.27.0, and CI pins 1.27.0, while:

  README.md (x2)            Go 1.26.4+
  CONTRIBUTING.md           Go 1.26.3+
  test/autobahn/README.md   Go 1.22+

The README number is the one that matters: it is what a user reads before
trying to build, and 1.26.4 cannot build a module whose go directive is
1.27.0. Rather than correct three copies of a number that has now drifted
twice, each site states the current floor AND points at the go directive as
the source of truth, so the next bump has one place to change.

CONTRIBUTING's parenthetical justified 1.26.3 by the stdlib CVEs govulncheck
surfaced on 1.26.2. That rationale expired with the floor it explained.

Also drops the stale "in v1.4.0" stamps the issue lists, plus four more it
does not: driver/postgres/rows.go, dsn.go and types_numeric.go. Every one
marks a limitation that is still true, dated to a release three minors back,
so a reader cannot tell whether the limitation or the date is the stale part.
The limitations stay; the dates go.

Left alone: SECURITY.md's "a Go 1.26.3 toolchain bump", which is a historical
statement about what v1.4.2 shipped, and driver/redis/state.go's "before
v1.4.0", which dates a past optimisation rather than a current limitation.
Both are correct as history.
@FumingPower3925
FumingPower3925 merged commit be12a98 into main Sep 11, 2026
34 checks passed
@FumingPower3925
FumingPower3925 deleted the chore/417-unify-go-floor branch September 11, 2026 04:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unify the Go version floor and drop stale version stamps

1 participant