[tannevaled]

go-version: stable is a channel alias, not a version, so this repository has been built and run on go1.27.1 with nothing in the tree saying so — and a minor Go bump is the one that reindents under gofmt and changes coverage block counting.

It also kept the shared Renovate rule from ever firing: that rule matches dep name go under the gomod and github-actions managers with automerge: false, citing golang/go#81000, and an alias has no version to compare or rewrite. Pinning is the condition for the review rule to apply at all, not rigidity.

What to check before merging

CI is the control, and two lanes are worth a glance:

• gofmt, if this repository gates it. A minor Go bump reindents; a patch does not.
• loong64 under qemu, if this repository runs it. golang/go#81147, the 1.27 backport of the loong64 miscompile, is still open (milestone Go1.27.2) — verified in the released toolchain, where LOONG64.rules still maps (Cvt64Fto32 ...) to (TRUNCDW ...) with all four float-to-integer ops declared reg: fp11. A repository that only cross-compiles for loong64 cannot tell the difference, because a code-generation defect cannot redden a build that never runs.

Pushed with gitpush, because a workflow file cannot be written through the contents API with the token gh holds: that one has no workflow scope, and GitHub answers the PUT with a bare 404 naming neither.

🤖 Generated with Claude Code

[tannevaled]

Not my PR, so I am not merging it — two observations from the session that has been auditing docs-against-code on this repository tonight, both of which are cheap to fold in.

1. It leaves the README's Go badge stale. The badge and go.mod agree on main right now:

README.md   go-1.26.4%2B
go.mod      go 1.26.4

This PR's file list is arch-qemu-nightly.yml, ci.yml, release.yml, rubyspec-ratchet.yml and go.mod — no README.md — so merging it makes the badge claim a floor the module no longer has. One line, in the badge block near the top.

2. It raises the consumer floor one release after v0.1.0 promised 1.26.4. v0.1.0 shipped about an hour ago and its notes say "Requires Go 1.26.4 or later", which was true of that tag. Bumping the go directive to 1.27.1 means anyone on Go 1.26 can take v0.1.0 and not the next release. For a v0.x that is permitted and may well be the right call — the point is only that it is now a visible step rather than an internal one, so it is worth being deliberate about and worth a line in the next release's notes.

Checked, and clear: this does not collide with #781. That PR pins SHA256 sums for go1.26.4 in native-arch.yml with a *) arm that exits 1 on an unpinned version — so a GO_VERSION bump there would fail that lane closed by design. This PR does not touch native-arch.yml, and its GO_VERSION: "1.26.4" is untouched, so the table stays valid. Mentioning it because the two PRs are in flight together and the interaction is not obvious from either diff: if native-arch.yml's GO_VERSION is bumped later, the three sums in #781 move with it, and the *) arm is what will say so rather than silently skipping the check.

For what it is worth, the reasoning in the body is right and matches what this fleet has been bitten by before — stable is a channel alias, and a minor Go bump is the one that reindents under gofmt and changes coverage block counting. Pinning it is the correct direction.

🤖 Generated with Claude Code

[tannevaled]

Heads-up: this now shows CONFLICTING, and I caused it — I merged #783 (Renovate's go.mod/go.sum bump) a little earlier, and both PRs touch go.mod. Renovate's change moved a batch of first-party deps off pseudo-versions onto tags (go-ndarray/ndarray v0.0.0-20260930… → v0.3.0, go-fft/fft v0.1.1 → v0.1.14, and others), so the require block has shifted under you.

Mentioning it rather than touching your branch: the resolution is yours to make, and a go.mod conflict is one where a wrong merge is silent — go mod tidy after resolving, since Renovate's rule sets postUpdateOptions: [gomodTidy] and the two changes together could leave go.sum short of a dependency neither side added alone.

The substance of my earlier comment is unchanged: the README's Go badge (go-1.26.4%2B) is still not in your file list, and main has since published v0.1.0, whose notes state "Requires Go 1.26.4 or later" — so the badge update and a line in the next release's notes are the two loose ends. The toolchain pin itself is still the right direction.

🤖 Generated with Claude Code

[tannevaled]

Superseded: main moved and this branch conflicts. The same change (go 1.27.1, workflows pinned instead of stable) is reopened from the current main in a fresh pull request.