Repository navigation
chore: lower the Go floor to 1.21 - #8
Merged
Merged
Conversation
go.mod said 1.27 because that happened to be the toolchain it was written with, which is not a reason. For a library the directive is a gate on who can import it, so it should state the oldest version the code actually needs. That is 1.21, from the clear() builtin in Params.Reset and the stdlib slices package in a test. Nothing else in the module reaches past it; go vet's stdversion analyser confirms no too-new stdlib symbol slipped through. The real constraint was the dependency. golang.org/x/image requires Go 1.23 from v0.25.0 and Go 1.25 from v0.39.0, so the pin dictated the floor. It is now held at v0.24.0, which requires only 1.18. That costs nothing measurable: regenerating the whole gallery against v0.24.0 produced a byte-identical result, so the older rasteriser draws exactly what the newer one does for everything this library asks of it. Dependabot is told not to offer the bumps that would undo this, with the reason written next to the rule. CI now builds against both the floor and the current release, on all three operating systems, and a step fails the floor leg if the matrix and go.mod ever disagree — a declared minimum that nothing builds against is a guess. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KwWthYNYf1egKNFrFS83Dm
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.
go.modsaidgo 1.27because that is the toolchain it was written with, whichis not a reason. For a library the directive gates who can import it, so it
should state the oldest version the code actually needs.
What the code needs
1.21 — from the
clear()builtin inParams.Resetand the stdlibslicespackage in one test. Nothing else in the module reaches past it, and
go vet'sstdversionanalyser confirms no too-new stdlib symbol slipped through.What was holding the floor up
The dependency.
golang.org/x/imagerequires Go 1.23 from v0.25.0 and Go 1.25from v0.39.0, so the pin was setting the floor, not the code. Pinned to
v0.24.0, which needs only Go 1.18, and Dependabot is told not to offer the
bumps that would undo it — with the reason written next to the rule.
The downgrade is free: at a fixed toolchain, v0.24.0 rasterises
byte-identically to v0.45.0 on both Linux and Windows.
What this turned up on the way
The first CI run failed the gallery check with all twelve images changed. The
obvious suspect was the x/image downgrade. It was not — it was the Go
toolchain: the gallery job read its version from
go.mod, so lowering thefloor moved that job from Go 1.27 to Go 1.21, and the compiler is free to
contract float expressions differently between releases. Same code, same
dependency, visually identical marks, slightly different pixels.
Pinning the gallery job to the current release made it pass, which isolates the
cause. So the reproducibility this library claims is now measured more
precisely than before:
x/imageversion (v0.24.0 vs v0.45.0)That is exactly why
Caps.ByteExactexists and why the suite compares floatrenderers by perceptual hash rather than by bytes. The gallery check is the one
byte-exact comparison in the project, so it now pins its toolchain, and
CONTRIBUTING says so — otherwise a contributor on the floor version would
regenerate the gallery and be told it is wrong.
CI
Builds against both the floor and the current release, across all three
operating systems, and a step fails the floor leg if the matrix and
go.modever disagree — a declared minimum that nothing builds against is a guess.
Branch protection: the required check contexts change shape, from
test (ubuntu-latest)totest (ubuntu-latest, 1.21)andtest (ubuntu-latest, stable). Updated as part of merging this.🤖 Generated with Claude Code
https://claude.ai/code/session_01KwWthYNYf1egKNFrFS83Dm