mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-07-31 20:32:20 +03:00
d3a9ad557d
The parallel-cycle model hands the frozen release/vX to the captain and cuts
release/vX+1 for everyone else. Phase 0a.0b step 3 then re-homes every open PR
onto the new cycle — today as a hand-run loop of gh pr edit --base.
Three things make that loop unreliable at exactly the moment it matters:
1. gh pr edit --base FAILS SILENTLY (v3.8.42). It exits 0 and leaves the base
untouched, so every edit needs a gh pr view --json baseRefName read-back.
A human mid-release skips that.
2. gh pr list caps at 30 results by default. A loop written without --limit
re-homes the first 30 of 148 and reports success.
3. Volume: the v3.8.49 freeze had 148 open PRs — roughly 450 API calls across
edit, verify and comment.
The script does the read-back on every PR, uses --limit 300, is idempotent (a
PR already on the next base is skipped, so a resumed release re-runs safely),
refuses to start when the next branch does not exist yet, and exits non-zero
listing any PR whose retarget did not take.
It also prints the reminder that it cannot solve the other half: PRs opened
AFTER it runs. Those need the repo default_branch pointed at the live cycle —
contributors open PRs against the default branch, and while that stays on main
they never target a release branch at all (6 such PRs on 2026-07-15).
classify() is pure and unit-tested: retarget open and draft PRs on the frozen
branch; never touch main (the release PR's own lane), an older shipped release,
or a PR already re-homed.
Refs #7307