The sub-module pin move in the release process has never been executed: tags v1.5.9 through v1.5.11 all ship go.mod files pinning an older celeris

[FumingPower3925]

mage CheckRelease on main (3b6184a) with VERSION=v1.6.0 exits 1: the four middleware/*/go.mod pins are at 1.5.8 while Version is 1.6.0. That is expected today — GOVERNANCE says the pins stay at the last released tag until the final prep pull request, and PrepRelease moves them.

The finding is what the audit noticed underneath that: the pins are at 1.5.8 while the last release is v1.5.11, and the same was true at v1.5.8 (pins at v1.5.5), v1.5.9 and v1.5.10. No PrepRelease-style pin move has happened for at least four consecutive releases. The sub-module tags middleware/<name>/v1.5.9, v1.5.10 and v1.5.11 therefore all point at trees whose go.mod requires an older celeris than the tag they carry.

That is not fatal — the replace directive in each sub-module makes local builds work, and a consumer who pins middleware/compress@v1.5.11 gets celeris v1.5.8 transitively unless they pin the root too, which most do. But it means the release process has a step that has never been executed, and v1.6.0 will be the first time anyone runs it.

The version-stamp gate added in celeris#582 is what makes this visible at all; before it, nothing checked. Two things to settle before the release:

1. Run VERSION=v1.6.0 mage PrepRelease in the final prep pull request and confirm CheckRelease then passes in release mode, not just consistency mode. That is the step with no precedent.
2. Decide whether the historical sub-module tags matter enough to re-cut. Probably not, but the decision should be explicit rather than inherited.

[FumingPower3925]

Rehearsed the never-executed step end to end, in an isolated worktree, against main 52b8501

VERSION=v1.6.0 mage PrepRelease works. Here is the whole sequence, measured rather than reasoned about.

Before. The gate fails exactly as this issue describes, and names the fix:

  ok       server.go                        1.6.0
  ok       README.md                        1.6.0
  MISMATCH middleware/compress/go.mod       1.5.8
  MISMATCH middleware/metrics/go.mod        1.5.8
  MISMATCH middleware/otel/go.mod           1.5.8
  MISMATCH middleware/protobuf/go.mod       1.5.8
Error: release stamps disagree with 1.6.0
(run: VERSION=v1.6.0 mage PrepRelease)

Note that the root version stamp and the README section are already at 1.6.0. Only the four sub-module pins are stale, which is the whole of the defect.

PrepRelease. Four one-line edits, nothing else touched:

  1.5.8 -> 1.6.0  middleware/compress/go.mod
  1.5.8 -> 1.6.0  middleware/metrics/go.mod
  1.5.8 -> 1.6.0  middleware/otel/go.mod
  1.5.8 -> 1.6.0  middleware/protobuf/go.mod

After. release stamps agree: 1.6.0, all six stamps ok.

The risk this issue was really about. A sub-module whose go.mod requires a celeris version that does not yet exist on the proxy is what broke probatorium's repin after #582, so the question is whether the moved pins break anything before the tag is published. They do not, because every sub-module carries replace github.com/goceleris/celeris => ../../. All four build and test clean with the pin at an unpublished v1.6.0:

module	result
compress	ok
metrics	ok
otel	ok
protobuf	ok

So CI's "Unit (root + middleware sub-modules)" job will pass on the release-prep pull request, and a consumer resolving middleware/compress@v1.6.0 gets celeris v1.6.0 from the proxy, which the release workflow publishes as the root tag before it tags the sub-modules.

One caveat carried forward. PrepRelease prints README.md needs the release prose (CheckRelease will say so until it has it) unconditionally, even in this run where the README section already exists and CheckRelease reports it ok. That is a misleading line, not a defect in the step. Worth a one-line fix when someone is next in the file.

Nothing was committed. The rehearsal ran in a throwaway worktree and the tree is unchanged.

[FumingPower3925]

Item 2 is settled by measurement, not by preference: never re-cut them

The question was whether the historical sub-module tags matter enough to re-cut, since middleware/<name>/v1.5.9 through v1.5.11 all point at trees whose go.mod requires an older celeris than the tag they carry.

They must not be re-cut, and the reason is not a judgement call. All of them are already recorded in the Go checksum database, sum.golang.org:

compress  v1.5.9   h1:oWP5XFol7BtYMsYj/PE38gKZnhY8OzvyKJ9z6X11pk...
compress  v1.5.11  h1:K14DFN+706bTvBzCMF00wx+OVwtP/SOW9d0Q1Qcr7...
metrics   v1.5.9   h1:RRxRSQgz/rGcuuPiGKv/CskLLuVVu2JVzWv5yCn5rsw...
metrics   v1.5.11  h1:Eojga1c2h1tk7CrgoLwr9gYnH9V9Z/LM+E0RtqBbCz...
otel      v1.5.9   h1:xrCzg3LDjxJ6nQSY2wDynhCSs9UYNREfYGhkQw+CCF0=
otel      v1.5.11  h1:4DGMuJjl0lKW4T9pkdBWM6jWRLbMMtpwx4+dbrMFBhI=
protobuf  v1.5.9   h1:21uhAqzYUwVSIaPniTukHwp6TNd2fiaItc319r0khe...
protobuf  v1.5.11  h1:B2CgK1VefBnG9//vPtkHhpaPqiBBMjGdECLV6NuzQ...

A version in the checksum database is immutable by design. Moving one of those tags to a different tree would not quietly correct anything: the next consumer to fetch it would get a hash that disagrees with the transparency log, and Go would stop with a checksum mismatch, which reads as a supply-chain compromise rather than as a fix. That is worse than the defect, for everyone who already has the old hash in their go.sum.

The remedy for a published version that is wrong is always a new version, never a moved tag. So the answer is no, and it is no permanently rather than "probably not for now".

What the defect actually costs, now that it is bounded

A consumer who pins middleware/compress@v1.5.11 and nothing else resolves celeris v1.5.8 transitively. Most pin the root as well, in which case minimal version selection takes the higher of the two and they get what they asked for. So the exposure is real but narrow, it is historical, and v1.6.0 is where it stops.

Item 1 is done

The rehearsal is in the comment above: PrepRelease moves all four pins, CheckRelease then reports release stamps agree: 1.6.0, and every sub-module builds and tests against the unpublished pin because each carries a replace to the repository root. Nothing was committed.

That leaves this issue waiting only on the real prep pull request during the release itself.

[FumingPower3925]

Item 1 is carried by the v1.6.0 checklist — this closes only when the release proves it

Checked against celeris main at 468ce53:

• mage PrepRelease exists (mage_release.go:200) and mage CheckRelease exists (mage_release.go:101).
• CheckRelease runs in Lint on every pull request (.github/workflows/ci.yml:48) and gates the release workflow (.github/workflows/release.yml:63–66).
• Release checklist: v1.6.0 #649 carries the step explicitly: VERSION=v1.6.0 mage PrepRelease (line 12), the four middleware/*/go.mod pins to v1.6.0 (lines 19–22), the sub-module tags and the proxy re-query (lines 41–45), and the sum.golang.org warning (line 47).

So nothing is missing from the process any more. What is still unmeasured is exactly the condition item 1 names, and only the release itself can satisfy it: the final prep pull request runs PrepRelease, and CheckRelease then passes in release mode rather than consistency mode — the step with no precedent in v1.5.8 through v1.5.11.

Leaving this open until that pull request shows it, and closing it then with the link.

Item 2 stays settled as recorded above: every middleware/*/v1.5.9 to v1.5.11 tag is in sum.golang.org, so none is re-cut.