Rename release branch main→release (Decision B, in-repo)#1114
Open
joeharris76 wants to merge 4 commits into
Open
Rename release branch main→release (Decision B, in-repo)#1114joeharris76 wants to merge 4 commits into
joeharris76 wants to merge 4 commits into
Conversation
Executes the in-repo half of Decision B of the branching-strategy review: rename the release-only branch from `main` to `release`. The GitHub branch rename + ruleset recreate are the maintainer's coordinated follow-up (docs/operations/branch-rename-runbook.md). Release-branch refs -> `release`: - Workflows: lint/test/perf-smoke/docs (+ Pages deploy gate), results-explorer-browser, cross-platform comment; renamed validate-main-pr.yml -> validate-release-pr.yml; release.yml verify-tag-on-main job + refs/heads ancestor gate -> verify-tag-on-release; test.yml base_ref release-gating conditionals. - Makefile: release-cut/release-finalize base, the `-s ours` origin/main alignment merge, --since-ref changelog boundary, checkout/pull, the main-release-only ruleset name (-> release-only), branch-protection guards, help text. - Scripts: ruleset_drift_check.py (parses release-only from the runbook), release.yml verify-tag docstring, generate_changelog_entry.py comments, todo_cli/pr_review_followups guards. - Docs/templates/config: release-guide, RELEASE_PR_TEMPLATE, repo-admin-settings (ruleset section the drift check parses), CONTRIBUTING, results-phase-2-runbook, pyproject Changelog URL, landing footer, blog links -> version tags, CLAUDE.md guard patterns. - Tests moved in lockstep: test_ruleset_drift, test_ruleset_drift_review_coverage, test_release_infrastructure, test_standardized_test_commands. Default-branch refs -> `develop` (NOT release; a Decision-A consequence the rename forces us to make correct): RELEASE_CANARY_BRANCH (the canary fires from the default branch, now develop, so its runs carry head_branch=develop) in validate-release-pr.yml + release_readiness_check.py; the nightly.yml scheduled-workflow-liveness comment. test_release_readiness updated to match. Verified safe / unchanged: PyPI trusted publishing (repo + release.yml filename + pypi environment, never a branch), GitHub Pages (deploy-pages), and the validate-base required-check context name (only the workflow file was renamed). Adds the decision record and the admin runbook; promotes the Decision B TODO to active (w1-w5 done; w6 = admin branch-rename + ruleset recreate). Verification: 135 affected tests pass; ruleset_drift_check parses release-only -> refs/heads/release; `ruff check .` clean; all workflows parse. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KPPPtRSp95b8JkUJcLEUcn
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c194f2d2b6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…he migration window (#1114 review) The main->release rename did a blanket develop|main -> develop|release text replace across five separate case-statement guards (pr-open, pr-fanout, pr-refresh, worktree-release-locked, worktree-pool-reset), which silently un-blocked main instead of adding release alongside it. A developer clone/worktree can still have a local main branch after the GitHub-side rename; without this guard, make pr-open from a stale main would push and open a develop PR from release-only history. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SKw2UhgHuzYPo3y5MfarD6
…view) seed-corpus opens PRs carrying results-data/bundles/ content, which release-cut curation removes from the release tree, and its chore/ head would be rejected by validate-release-pr.yml. So the base must be develop (integration semantics), not the release branch. This corrects the earlier `--base release` edit, matching the concern raised in the parallel PR #1027's review. Flagged in-comment for maintainer confirmation. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KPPPtRSp95b8JkUJcLEUcn
…ents The rename TODO now records the reconciliation state: w1-w5 landed via PR #1114 (superseding the duplicate #1027), the default-branch-vs-release classification (RELEASE_CANARY_BRANCH + seed-corpus -> develop), and the migration-window guard fix (develop|main|release). Fixes the stale "runbook not yet committed" prior_art note and points w6 at PR #1114 + the committed runbook. Only w6 (admin) remains. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KPPPtRSp95b8JkUJcLEUcn
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#1027 (from an earlier session) was a parallel attempt at this same Decision B rename. This PR is a strict superset: file-set comparison shows every file #1027 touches is also touched here, plus 16 more. To make it the single source of truth, this PR now also incorporates the two things #1027 got right that this PR originally didn't:
seed-corpus.ymlbase →develop(notrelease): it carriesresults-data/bundles/content that release-cut curation removes from the release tree, and itschore/head would be rejected byvalidate-release-pr.yml. chore: rename release branch main->release in-repo (w1-w4) #1027 correctly flagged that renaming it toreleasewas wrong. (chore: rename release branch main->release in-repo (w1-w4) #1027 left it asmain, which breaks post-rename;developis the correct integration base.)mainblocked during the migration window (develop|main|release, notdevelop|release): a blanket text-replace silently un-blocked a stale localmain. Fixed in-branch with a regression test.Extra improvements unique to this PR (not in #1027):
pyproject.tomlChangelog URL →blob/release;RELEASE_CANARY_BRANCH → develop(the default-branch-vs-release-branch classification, incl.release_readiness_check.py+nightly.yml);single-repo-migration.md,CLAUDE.mdguard patterns,_blog/source posts, decision record. #1027 can be closed as superseded.Description
The in-repo half of Decision B — rename the release-only branch
main→release. The GitHub branch rename + ruleset recreate are your coordinated follow-up (seedocs/operations/branch-rename-runbook.md); this PR must merge before that admin step.release.yml(a CODEOWNERS soundness path), so auto-merge is withheld — this needs your Code Owner review.The nuance that matters (please focus review here)
mainreferences split into two meanings, classified rather than blindly renamed:release(the rename proper).develop— NOTrelease.RELEASE_CANARY_BRANCHmeans "the branch that owns the canary runs"; the canary fires from the default branch (nowdevelopafter Decision A), and its runs carryhead_branch=develop. Renaming it toreleasewould be a soundness bug. Same for thenightly.ymlliveness comment andseed-corpus.yml's base.test_release_readiness.pyassertsbranch=develop.What changed (release-branch →
release)lint/test/perf-smoke/docs(+ Pages deploy gate),results-explorer-browser, cross-platform comment; renamedvalidate-main-pr.yml→validate-release-pr.yml;release.ymlpublish gateverify-tag-on-main→verify-tag-on-release;test.yml's 6base_refconditionals.-s oursalignment merge,--since-refboundary, checkout/pull,main-release-only→release-only, protected-branch guards (develop|main|release), help text.ruleset_drift_check.py(parsesrelease-only),release_readiness_check.py, changelog-generator,todo_cli/pr_review_followupsguards.release-guide,RELEASE_PR_TEMPLATE,repo-admin-settings,CONTRIBUTING,results-phase-2-runbook,pyproject.tomlChangelog URL, landing footer, blog → version tags,CLAUDE.md. New decision record +branch-rename-runbook.md.Verified safe / unchanged
release.ymlfilename +pypienv, never a branch); GitHub Pages (deploy-pages); thevalidate-baserequired-check context name (only the workflow file was renamed).Testing
test_release_infrastructureincl. the new guard test; 135 across the wider affected set on the prior push).release-only → refs/heads/release;ruff check .clean; all workflows parse.Notes
docs/operations/branch-rename-runbook.md: renamemain→release, recreate the ruleset asrelease-only. Do them together with the merge.🤖 Generated with Claude Code
https://claude.ai/code/session_01KPPPtRSp95b8JkUJcLEUcn