Repository navigation
Cut v0.3.0: the Release-As footer was dropped from #60 and #62 #63
Description
Problem
v0.3.0 was meant to be cut by a Release-As: v0.3.0 footer in the squash body of #60, and then of #62 (closes #61). Both merges used the repo default squash body, so the footer never reached main.
- fix(release): derive the version bump from commit types (#54) #60 shipped as v0.2.27.
- The release run for docs: say the default squash body drops footers; correct the #54 example (#61) #62 (
37709033894) was cancelled before its version job, so nothing was tagged.
The "Worked Examples" table in docs/release-versioning.md now wrongly says #61 ships as v0.3.0.
Proposed solution
Correct the worked example: #62 also lost its footer and its release was cancelled. Merge this fix with a squash body that carries Release-As: v0.3.0, using gh pr merge --squash --body-file. Its release covers v0.2.27..HEAD, which includes #62, so #62 and this fix ship together as v0.3.0.
Alternatives considered
- Footer on the Routing parity: TS path-wide exec deny; Go matchEndpoint accepts endpoint subpaths #49 merge. Rejected by the maintainer. v0.3.0 should be cut on its own, ahead of Routing parity: TS path-wide exec deny; Go matchEndpoint accepts endpoint subpaths #49.
- Empty commit. Rejected: GitHub cannot squash-merge a PR with no file changes.
Activity
docs: record that #62 lost its footer too; cut v0.3.0 here (#63) (#64)
abienkowski commentedon Oct 8, 2026
Reopened. #64 was merged with an empty squash body, so the footer missed
mainfor the third time. Release run37774150988was cancelled before tagging. Root cause: the footer only ever existed in a separate merge-message file. The branch commit had no body, and GitHub's default squash message for a single-commit PR is that commit's own message. Fix: putRelease-As: v0.3.0in the branch commit's message itself, so the default squash carries it, and update the doc to recommend that.docs: put release footers in the commit itself; cut v0.3.0 (#63) (#66)