release-please miscomputes the next rc after a manual-tag cut (#287's footer-free flow left rc.3 unrecognized; #306 regressed to rc.2)

[StefanSteiner]

Symptom

After 1.0.0-rc.3 shipped, the next release-please PR (#306) computed the manifest change 1.0.0-rc.3 → 1.0.0-rc.2 — a backward move to an already-published version — and its changelog re-listed rc.3's already-shipped commits (#281, #286, #289, #290, #295, #280) as if unreleased. Left unfixed, merging it would have set the workspace version backward to a version crates.io has already published.

Ground truth was correct throughout: .release-please-manifest.json on main read 1.0.0-rc.3, version.txt read 1.0.0-rc.3, tags v1.0.0-rc.1/2/3 all existed, rc.3 was a published prerelease on crates.io, and #282's label was correctly autorelease: tagged. Only release-please's computation for the next PR was wrong.

Root cause (hypothesis — needs a dry-run to confirm)

#306's own changelog is the tell: under "Miscellaneous Chores" it records release 1.0.0-rc.1 (7bf2dff) and release 1.0.0-rc.2 (a9fe1b0) as prior releases, but not release 1.0.0-rc.3. So release-please's prerelease versioning strategy re-derived the rc counter from the last release marker it recognized — rc.2 — and miscomputed the next as rc.2.

Why no rc.3 marker? The rc.1 and rc.2 releases were pinned with explicit Release-As: 1.0.0-rc.N footers, which left recognizable release 1.0.0-rc.N chore commits. rc.3 was the first release cut through the new automated, footer-free prerelease config added in #287 — its release PR (#282) was titled generically "chore: release main", and the tag was created by hand (skip-github-release: true). That combination left no release 1.0.0-rc.3 fingerprint that the prerelease strategy anchors on.

So the likely mechanism: #287's footer-free automation is incompatible with this repo's skip-github-release + manual-tag flow. The footer that #287 removed appears to have been load-bearing for release-tracking under manual tagging. The dry-runs that validated #287 tested version computation from a manifest base; they did not exercise a full cut-and-manual-tag cycle, which is where this surfaced.

Immediate fix (applied)

Landed an empty commit on main with Release-As: 1.0.0-rc.4 (the documented override for "the release PR shows the wrong version"). release-please regenerated #306 in place to 1.0.0-rc.4 (manifest 1.0.0-rc.3 → 1.0.0-rc.4). Nothing was released.

Why this needs follow-up

If the hypothesis holds, every future rc cut through the manual-tag flow will miscompute the next version and need a Release-As footer — which negates the automation #287 was meant to provide, and contradicts docs/GITHUB_OPERATIONS.md, which now tells maintainers the rc line "bumps itself with no footer needed." Two things should be settled:

1. Confirm the mechanism with a dry run that reproduces a full cut: manifest at rc.N, a manually-created vX.Y.Z-rc.N tag, generic-titled release PR, then run release-please and observe whether it computes rc.(N+1) or regresses. Compare against a footer-pinned cut.
2. Decide the durable fix, e.g. one of:
   • Keep pinning each rc with a Release-As footer (revert chore: automate the release-candidate version bump #287's "no footer needed" claim in the docs), or
   • Stop skipping the GitHub release so release-please creates the tag and records its own marker, or
   • Give the release PR a version-bearing title so a recognizable release X.Y.Z marker lands.
3. Re-examine the 1.0.0 graduation plan (removing the prerelease keys) in light of this — the interaction between the manual-tag flow and the prerelease strategy may change what "graduating" requires.

Provenance

Surfaced when #306 was flagged as computing rc.2 after rc.3 shipped. Fix verified: #306 now computes 1.0.0-rc.4. main manifest, tags, releases, and crates.io all confirmed consistent at rc.3 before the fix.