Background
Follow-up to #4000 / #4018 and PR #4122, which made the release/* final-promotion path executable (stable release[X.Y.Z] from the matching release/X.Y.Z branch + CI-tip validation). PR #4122 deliberately deferred the forward-port automation (this issue) rather than bundle it into a release-critical release.rake change.
What's still manual
The release-train runbook's close-out (step 5) forward-ports the final CHANGELOG collapse back to main and bumps main to the next dev version with hand-run git commands:
git checkout main && git pull --rebase
git cherry-pick -x <changelog-collapse-sha> # the rc-section collapse commit
git push
# then bump main to the next dev version if not already
During RC stabilization (step 3), each fix that lands on release/X.Y.Z must also be cherry-picked (-x) to main.
Why it wasn't automated in #4122
Its safe shape is conditional, which is why a naive helper is risky:
- Whether to take the version-bump commit at all depends on how far
main has drifted — if main is already past the release version (e.g. 17.1.0.dev), cherry-picking the bump-to-17.0.0 commit conflicts and would regress main's version. Only the CHANGELOG changes should be taken in that case (see the step-5 caveat in the runbook).
- It must cherry-pick only the fix / CHANGELOG-collapse commits, never the rc
Bump version to …rc.N commits.
It is not a release blocker (nothing aborts), unlike the stable-promotion guard that #4122 resolved.
Proposed helper (sketch)
A rake/script helper (e.g. script/release-forward-port or a rake "release:forward_port[...]") that:
- Takes the fix/CHANGELOG SHAs (or derives them from the
release/X.Y.Z branch, excluding Bump version to * commits).
- Cherry-picks them
-x onto an up-to-date main (or a PR branch when main is protected).
- Detects the version-drift case and either skips the version-bump commit or takes only the CHANGELOG hunks, surfacing a clear message instead of leaving a conflict.
- Is dry-run-able and idempotent (skips already-forward-ported commits —
-x makes them auditable).
Acceptance
Refs
Background
Follow-up to #4000 / #4018 and PR #4122, which made the
release/*final-promotion path executable (stablerelease[X.Y.Z]from the matchingrelease/X.Y.Zbranch + CI-tip validation). PR #4122 deliberately deferred the forward-port automation (this issue) rather than bundle it into a release-criticalrelease.rakechange.What's still manual
The release-train runbook's close-out (step 5) forward-ports the final CHANGELOG collapse back to
mainand bumpsmainto the next dev version with hand-rungitcommands:During RC stabilization (step 3), each fix that lands on
release/X.Y.Zmust also be cherry-picked (-x) tomain.Why it wasn't automated in #4122
Its safe shape is conditional, which is why a naive helper is risky:
mainhas drifted — ifmainis already past the release version (e.g.17.1.0.dev), cherry-picking the bump-to-17.0.0commit conflicts and would regressmain's version. Only the CHANGELOG changes should be taken in that case (see the step-5 caveat in the runbook).Bump version to …rc.Ncommits.It is not a release blocker (nothing aborts), unlike the stable-promotion guard that #4122 resolved.
Proposed helper (sketch)
A
rake/scripthelper (e.g.script/release-forward-portor arake "release:forward_port[...]") that:release/X.Y.Zbranch, excludingBump version to *commits).-xonto an up-to-datemain(or a PR branch whenmainis protected).-xmakes them auditable).Acceptance
release/*fixes tomainwithout dragging rc version-bump commits.main-already-bumped case (CHANGELOG-only) with a clear message rather than a raw conflict.Refs
internal/contributor-info/release-train-runbook.md(steps 3 and 5, and the GAP 2 follow-up note)