Repository navigation
README: the Go badge reads go.mod instead of restating it - #810
Merged
Merged
Conversation
The badge has now been corrected three times for the same reason, and the third time it was corrected and then UNDONE: on 2026-10-10 Renovate force-pushed its branch over a commit that had fixed the badge and gone green on every lane, reinstating 1.27.1 against a 1.27.2 directive. A number a human has to retype is a number that comes back. So it stops being retyped. shields.io's github/go-mod/go-version endpoint reads the directive out of the repository -- verified against this one, where it renders "Go: v1.27.1" -- which takes the badge out of the maintenance loop entirely, the same way the release badge stopped naming a version in #801. The guard gets STRICTER, not weaker, in three ways: A dynamic badge is not compared against a value, because it cannot disagree with one. Instead the test now fails if a LITERAL badge is left beside it -- that would be a second, rottable copy, which is the thing being removed. The number of hand-written statements required drops from 2 to 1 only when the badge is dynamic. Demanding two would force somebody to add a rottable number back. It never drops to 0: a README that states the minimum nowhere would pass a check for "no WRONG statement" by saying nothing at all, and a reader deciding whether they can depend on the module needs the number on the page. No badge of either kind is still a hard failure. Checked in four directions, and one of the four controls was itself wrong, which is worth recording: setting the directive to a nonexistent 1.27.9 made `go test` refuse to START, so the guard looked green when it had simply never run. The file had changed -- which is what I had verified -- and the test had not executed, which is what I had not. Redone with 1.27.2 it fails correctly: README states a Go minimum of 1.27.1 in "Go 1.27.1+"; go.mod requires 1.27.2 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tannevaled
added a commit
that referenced
this pull request
Oct 10, 2026
Renovate force-pushed this branch over 12f5759 -- a commit that had corrected both statements of the Go minimum and gone GREEN on ci and rubyspec-ratchet -- reinstating 1.27.1 against the 1.27.2 directive the same branch sets. So the badge guard fails again, on exactly the lines it failed on before. Re-applied. The durable half is #810, which replaces the badge with one that READS go.mod (shields.io's github/go-mod/go-version) so there is one hand-written copy left instead of two; that one still has to be corrected by hand, and the guard still names it every time. Worth knowing for whoever reads these lanes next: the five red checks on this branch were never about these dependency bumps. They were `go: go.mod requires go >= 1.27.2 (running go 1.27.1; GOTOOLCHAIN=local)` -- every lane stopped at `go vet`, before a single dependency was exercised. The other half of that pair was #808, now merged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tannevaled
added a commit
that referenced
this pull request
Oct 11, 2026
The only red check left on this branch, and the LAST hand-written copy of the number: #810 made the badge read go.mod, so there is one statement to correct instead of two, and the guard named it exactly. readme_go_floor_test.go:83: README states a Go minimum of 1.27.1 in "Go 1.27.1+"; go.mod requires 1.27.2 Everything else on this branch is green -- internal/vm passes in 373s on arch amd64, and the dependency bumps themselves are being exercised for the first time, since every earlier run on this branch stopped at `go vet` on the toolchain pin (#808, merged). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three corrections, and the third was undone
The Go badge has been corrected for the same reason three times (#793, #795,
and once more yesterday) — and the third time it was corrected and then
reverted: on 2026-10-10 Renovate force-pushed
renovate/depsover acommit that had fixed the badge and gone green on every lane, reinstating
1.27.1against a1.27.2directive.12f575945cisuccess,rubyspec-ratchetsuccess88c62b8b5cifailure on the badge guardA number a human has to retype is a number that comes back. So it stops being
retyped: shields.io's
github/go-mod/go-versionendpoint reads the directiveout of the repository — verified against this one, where it renders
Go: v1.27.1— the same way the release badge stopped naming a version in #801.The guard gets stricter, not weaker
Three ways, because removing a thing to check is exactly when a guard quietly
becomes decorative:
with one. Instead the test now fails if a literal badge is left beside it —
that would be a second, rottable copy, which is the thing being removed.
the badge is dynamic. Demanding two would force someone to add a rottable
number back. It never drops to 0: a README that states the minimum nowhere
would pass a check for "no wrong statement" by saying nothing, and a reader
deciding whether they can depend on the module needs the number on the page.
Checked in four directions — and one of my controls was wrong
go.modmoves, prose left behindThe second one took two attempts, and the first attempt is the part worth
reporting. Setting the directive to a nonexistent
go 1.27.9madego testrefuse to start (
go: go.mod requires go >= 1.27.9), so the guard lookedgreen when it had simply never run. The file had changed — which is what I had
verified — and the test had not executed, which is what I had not. Redone with
a real
1.27.2:A control has to break the value with something plausible, or it breaks the
harness instead and the silence reads exactly like a pass.
🤖 Generated with Claude Code