Release checklist: v1.6.0 #649

Backfilled by hand. The workflow that opens these fires on milestone: created, so the milestones that already existed when it landed never got one.

Opened automatically because the v1.6.0 milestone was created. Close it when every stamp below reads 1.6.0.

Only the celeris stamps are enforced: mage CheckRelease runs in Lint on every pull request and fails while any of them disagrees. Everything under the second heading is enforced by nothing, which is why it is written down here.

celeris — enforced by mage CheckRelease

One command does all of these:

VERSION=v1.6.0 mage PrepRelease

Or by hand:

• server.go → const Version = "1.6.0"
• README.md → ## What's new in v1.6.0
• middleware/compress/go.mod → github.com/goceleris/celeris v1.6.0
• middleware/metrics/go.mod → github.com/goceleris/celeris v1.6.0
• middleware/otel/go.mod → github.com/goceleris/celeris v1.6.0
• middleware/protobuf/go.mod → github.com/goceleris/celeris v1.6.0
• README.md — replace the placeholder under that heading with the real release prose. CheckRelease fails while the placeholder remains, so this one cannot be forgotten silently.

The other three repositories — enforced by nothing

• loadgen version.go, const fallbackVersion — only if loadgen is being released too; it versions independently of celeris.
• loadgen internal/integrationtest/testserver/go.mod — the celeris pin.
• probatorium — repin celeris in all ten modules that require it, to the released tag rather than a pseudo-version:

  for m in $(grep -rl 'goceleris/celeris v' --include=go.mod . | grep -v .claude); do
    (cd "$(dirname "$m")" && go get github.com/goceleris/celeris@v1.6.0 && go mod tidy)
  done

• docs — publish this version's benchmark results, so the dashboard is not left a release behind. It has been, for three releases running.

After you publish the release

These run on their own from .github/workflows/release.yml. They are listed so a failure is recognisable rather than invisible:

• middleware/compress/v1.6.0 is tagged
• middleware/metrics/v1.6.0 is tagged
• middleware/otel/v1.6.0 is tagged
• middleware/protobuf/v1.6.0 is tagged
• the Go module proxy is asked for the root module and every sub-module, then re-queried to confirm each is really available

Neither runs if the stamps disagree. A sub-module tag pinning the wrong celeris version cannot be corrected afterwards: every published tag is recorded in sum.golang.org, and moving one gives existing consumers a checksum mismatch that reads as a supply-chain compromise. The remedy for a bad published version is always a new version.