Release tripwire: rc.3 needs a Release-As footer on main, in the squash commit body

[StefanSteiner]

Before merging the release PR for rc.3, a Release-As: 1.0.0-rc.3 footer must be on main. Without it the release PR is wrong, and nothing downstream will catch it.

Current state

main is at v1.0.0-rc.2. The three commits since it carry no Release-As: footer, and one of them is a fix:. #282 has therefore computed 1.0.1-rc.2.

That is not a mis-parse — it is what the config asks for. release-please-config.json has no prerelease keys (prerelease, prerelease-type, versioning), so release-please applies its default strategy, which bumps major.minor.patch and carries the existing -rc.N suffix along untouched. Verified with npx release-please@17.11.2 release-pr --dry-run (17.11.2 is the version release-please-action@v5 pins), which reproduces 1.0.1-rc.2 exactly:

Highest-precedence commit since v1.0.0-rc.2	Computed version
fix: (today's actual state)	1.0.1-rc.2
feat:	1.1.0-rc.2
feat!: / fix!: / BREAKING CHANGE:	2.0.0-rc.2
any of the above + Release-As: 1.0.0-rc.3	1.0.0-rc.3

The last row is the only correct one. This is exactly the outcome a9fe1b0 was written to prevent for rc.2, and its commit message already spells out why bump-minor-pre-major does not help: it is gated on version.isPreMajor (major < 1), which has been false since 1.0.0-rc.1.

Why this is not recoverable after the fact

1.0.1-rc.2 sorts above 1.0.0. If it reaches crates.io, a later 1.0.0 final becomes a downgrade, and the 1.0.0 rc line can never be completed cleanly. cargo yank hides a version but never frees the number, so there is no undo.

Neither publish workflow would stop it. Both validate only that the tag is well-formed and matches Cargo.toml:

• release.yml checks ^v[0-9]+\.[0-9]+\.[0-9]+(-(rc|alpha|beta)\.[0-9]+)?$, then compares against hyperdb-api-core/Cargo.toml and hyperdb-compile-check/Cargo.toml.
• npm-build-publish.yml checks the same shape against the workspace Cargo.toml.

v1.0.1-rc.2 passes the regex, and the release PR itself wrote 1.0.1-rc.2 into every Cargo.toml, so the consistency check agrees too. The version is wrong but perfectly self-consistent. The version in the release PR title is the only gate.

Landing the footer

Recent PRs are squash-merged, so the footer must be in the squash commit body. A footer that exists only on a branch commit is discarded — this is the part that is easy to get wrong.

v1.0.0-rc.2's footer survived only because #254 landed as a real merge commit (fa35a45, two parents), preserving the empty chore: release 1.0.0-rc.2 commit that carried it. v1.0.0-rc.1 landed the same way. Every commit on main since then is single-parent.

Two working options:

1. Squash-merge a PR and put the footer in the squash body. Edit the commit-message box in the merge dialog; the footer must survive into the commit that lands on main.

2. Push a direct empty commit — enforce_admins is false on main, so an admin can bypass the review requirement:

   git commit --allow-empty -m "chore: release 1.0.0-rc.3" -m "Release-As: 1.0.0-rc.3"
   git push upstream main

Leave #282 alone

Do not close it, retitle it, or hand-edit its version. Once the footer is on main, release-please recomputes and force-pushes its own branch, and the PR self-corrects in place to 1.0.0-rc.3. This is fa35a45's own recorded guidance from the rc.2 cut:

chore(main): release … PR computed from #253's commits alone — before this PR's Release-As: footer is on main. That PR will show the wrong version. It updates itself once this PR lands; leave it alone until then.

Confirm the title reads 1.0.0-rc.3 before merging.

Follow-up: make this unnecessary

Adding three keys to release-please-config.json removes the human step entirely. Verified by dry run, not assumed:

"prerelease": true,
"prerelease-type": "rc",
"versioning": "prerelease"

With those, fix:, feat:, and feat!: all compute 1.0.0-rc.3. Exiting the rc line stays easy: flipping "prerelease" to false makes the next release 1.0.0, and a Release-As: 1.0.0 footer still works. One caveat — the keys must be removed once 1.0.0 ships, or the next fix: computes 1.0.1-rc (also verified). That failure is visible in the release PR title, unlike the current one.

Worth doing as its own reviewed PR with the dry run attached. Rationale and the full matrix are in docs/GITHUB_OPERATIONS.md → Automating the rc line.

[StefanSteiner]

Superseded by #287 — the footer is no longer needed for rc.3

#287 implements the "Follow-up: make this unnecessary" section of this issue. It adds the three prerelease keys to the . package in release-please-config.json and removes the two inert bump-minor-pre-major keys.

Once #287 merges, no Release-As: 1.0.0-rc.3 footer is required. Dry runs against the literal #287 branch — which is main + that one config commit, i.e. exactly the post-merge state — compute 1.0.0-rc.3:

$ npx release-please@17.6.0 release-pr \
    --repo-url=StefanSteiner/hyper-api-rust \
    --target-branch=chore/automate-rc-versioning \
    --config-file=release-please-config.json \
    --manifest-file=.release-please-manifest.json \
    --token="$(gh auth token)" --dry-run

Would open 1 pull requests
<details><summary>1.0.0-rc.3</summary>
## [1.0.0-rc.3](…/compare/v1.0.0-rc.2...v1.0.0-rc.3) (2026-09-06)

The harness reproduced this issue's live 1.0.1-rc.2 from the current config first, so the comparison is apples-to-apples. All three commit shapes this issue tabulates (fix:, feat:, feat!:) collapse to 1.0.0-rc.3 under the new config, and Release-As: still overrides when present. Full 20-row matrix in #287.

Expected mechanism, matching this issue's "Leave #282 alone" guidance: when #287 lands on main, release-please re-runs and #282 self-corrects in place from 1.0.1-rc.2 to 1.0.0-rc.3. Same behaviour this issue describes for the footer — just triggered by the config change instead. Still don't close, retitle, or hand-edit #282, and still confirm the title reads 1.0.0-rc.3 before merging it.

What replaces this tripwire

The requirement doesn't vanish, it moves — and this is the part worth carrying forward from this issue:

The prerelease keys must be removed (or prerelease flipped to false) when 1.0.0 final ships. Otherwise the next fix: after 1.0.0 computes 1.0.1-rc — verified by dry run — and every subsequent stable release becomes an rc.

That is a strictly better tripwire than the one this issue documents, for the reason this issue itself identifies:

	This issue (footer per rc)	After #287
Correct action needed	on every rc release	once, at 1.0.0
Version if forgotten	1.0.1-rc.2	1.0.1-rc
How you find out	nothing objects	wrong version in the PR title
Recoverable?	no, once published	yes, before merging

The failure this issue is about is silent and terminal — 1.0.1-rc.2 sorts above 1.0.0, passes both publish workflows' regexes, and matches the Cargo.toml the release PR wrote. The new failure is a visibly-wrong version in the release PR title, before anything is tagged, fixed by the config edit that was missed. #287 documents it in three places: the release checklist at step 3, a note beside the bump table, and a dedicated Graduating to 1.0.0 section in docs/GITHUB_OPERATIONS.md.

Two corrections to this issue

• release-please-action@v5 bundles release-please 17.6.0, not 17.11.2. This issue (and the docs docs: correct the release-process docs against the real release-please setup #285 landed) state 17.11.2 is "the version release-please-action@v5 pins". The action's package.json declares only the range ^17.6.0; its package-lock.json and its bundled dist/index.js at the v5 tag both resolve to 17.6.0 (dist/index.js line 48369: exports.VERSION = '17.6.0';, inside release-please's own x-release-please-start-version markers). The whole matrix was re-run on 17.6.0 and cross-checked on 17.11.2 — both agree on every case, so no conclusion here changes, but 17.6.0 is the faithful version to re-verify against. chore: automate the release-candidate version bump #287 fixes the doc line.
• The pointer at the end of this issue goes stale. docs/GITHUB_OPERATIONS.md → Automating the rc line is removed by chore: automate the release-candidate version bump #287 (the thing it proposed is now adopted). Its content is folded into Pre-releases, Graduating to 1.0.0, and Re-verifying the prerelease behaviour.

Not closing this

Leaving it open deliberately — #287 isn't merged yet, and until it is, everything this issue says about #282 and the footer still applies verbatim. Worth closing once #287 lands and #282's title flips to 1.0.0-rc.3, which is also the real-world confirmation that the change works.

[StefanSteiner]

Superseded by #287 (merged).

This issue tracked a manual tripwire: that cutting rc.3 required landing a Release-As: 1.0.0-rc.3 footer on main before the release PR would compute the right version, and that the footer had to sit in the squash commit body to survive a squash merge.

#287 removed the need for it entirely by adding prerelease: true / prerelease-type: rc / versioning: prerelease to the release-please config, so any conventional commit now bumps the rc automatically. Verified: release PR #282 computes 1.0.0-rc.3 with no footer present.

The footer mechanism still works as an override for pinning a specific version, and that is documented in docs/GITHUB_OPERATIONS.md. The standing item that replaces this tripwire — removing the prerelease keys when 1.0.0 final ships, or the next fix: computes 1.0.1-rc — is documented there and in the release checklist. Closing as no longer actionable.