0001 — A release on a protected branch takes two tp release runs, not one that waits
Status: accepted; amended by 0006 (the release branch replaces release/vX.Y.Z; the two runs stand)
Date: 2026-10-03
Story: #26 / stories/005-tp-release-via-pull-request.md
Context
On a protected main the release commit must go through a pull request
and a human must merge it. Between opening the PR and tagging the merged
commit, minutes or days may pass. The question was whether tp release
is one process that opens the PR and waits for the merge, or two separate
runs with the forge holding the state in between.
Options
| Option | Complexity | Testability | Domain clarity | Operational risk |
|---|---|---|---|---|
| A. One run that polls the forge until merged, then tags | Polling loop, timeouts, interrupt handling | Needs a clock and a fake forge that changes state mid-run | "Run the release" is one command, but it may sit for hours | A closed terminal, sleep or network blip aborts a half-done release; the resume path is the same as B anyway |
| B. Two runs: first opens the PR and exits; second finds the merged PR, tags and publishes | Two code paths selected from forge state | Each run is a pure function of repo + forge state; the whole table is testable against a bare repo and a fake forge | The forge's PR list is the single source of what is pending | Nothing to keep alive; a crash between the two leaves only a branch and a PR, both visible on the forge |
Decision
B. The release branch and its pull request are the whole state, so the
second run needs nothing local: it fetches, fast-forwards, checks the
CHANGELOG names the merged version, tags and publishes. A tp release
that finds the PR still open prints its URL and exits 0, which is the
only "waiting" the tool does.
Consequences
Easier: no long-lived process, no polling budget, a crash is recoverable by running again. The second run decides its work from the forge, so a project can release again after any number of merged PRs without remembering which version it chose.
Harder: the release is two commands rather than one, and a project with a pending release PR cannot start the next version until it is merged or closed; the tool says so and points at the PR.