Repository navigation
Add start-beta-process command to cut beta pre-releases - #74464
Open
vatsrahul1001 wants to merge 1 commit into
Open
vatsrahul1001 wants to merge 1 commit into
vatsrahul1001 wants to merge 1 commit into
Conversation
vatsrahul1001
requested review from
amoghrajesh,
ashb,
bugraoz93,
choo121600,
ephraimbuddy,
gopidesupavan,
jason810496,
jedcunningham,
jscheffl,
potiuk,
shahar1 and
vincbeck
as code owners
October 8, 2026 14:20
vatsrahul1001
force-pushed
the
beta-aware-start-rc-process
branch
from
October 8, 2026 14:35
52d5255 to
67b1076
Compare
vatsrahul1001
changed the title
vatsrahul1001
changed the title
vatsrahul1001
force-pushed
the
beta-aware-start-rc-process
branch
from
October 8, 2026 14:54
67b1076 to
7373368
Compare
kaxil
reviewed
Oct 8, 2026
kaxil
approved these changes
Oct 8, 2026
vatsrahul1001
force-pushed
the
beta-aware-start-rc-process
branch
2 times, most recently
from
October 9, 2026 09:32
7271623 to
0bde580
Compare
vatsrahul1001
changed the title
vatsrahul1001
force-pushed
the
beta-aware-start-rc-process
branch
2 times, most recently
from
October 9, 2026 13:37
0ff7b12 to
2a6eefd
Compare
Betas are cut from vX-Y-test only: there is no vX-Y-stable branch yet and no sync PR (a sync PR exists only to carry changes from vX-Y-test into vX-Y-stable for an rc or final), and there is no vote. start-rc-process requires the stable branch and a sync branch, so a beta had to be cut by hand. A dedicated command keeps start-rc-process untouched and models the real beta flow: tag the vX-Y-test tip (the version-bump and release-notes commits are pushed there beforehand through normal PRs) and resolve the constraints through the release-constraints workflow from vX-Y-test, the same way an rc does. The workflow is taught to accept beta versions and treat them as pre-releases: provider rc waves are allowed and the result lands on its own constraints-X.Y.0bN branch and tag, leaving the shared constraints-X-Y branch untouched (only a final moves it).
vatsrahul1001
force-pushed
the
beta-aware-start-rc-process
branch
from
October 11, 2026 14:37
2a6eefd to
6c4ba97
Compare
This branch has not been deployed
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.
Betas are cut from
vX-Y-testonly — there's novX-Y-stablebranch yet, no sync PR (a sync PR only exists to carry changes fromvX-Y-testintovX-Y-stablefor an rc/final), and no vote.start-rc-processrequires the stable branch and a sync branch, so until now a beta had to be cut by hand.Rather than bolt beta special-cases onto
start-rc-process, this adds a dedicatedbreeze release-management start-beta-processand leavesstart-rc-processuntouched. The version-bump and release-notes commits are pushed tovX-Y-testthrough normal PRs beforehand; the command then:vX-Y-testexists (no stable branch needed),vX-Y-testtip and tags the beta there — so the tag is exactly what was pushed (3.3.0b1was mistakenly tagged on a divergent local copy; this avoids that),start-rc-processuses,release-constraintsworkflow fromvX-Y-test, the same way an rc does.To support that last point, the
release-constraintsworkflow is taught to accept beta versions (X.Y.0bN) and treat them as pre-releases, exactly like an rc: provider rc waves are allowed and the result lands on its ownconstraints-X.Y.0bNbranch and tag, leaving the sharedconstraints-X-Ybranch untouched. The rc and final behaviour is unchanged — a final still pins released providers and commits ontoconstraints-X-Y.The only change to the existing
start-rc-processcode is renamingRC_PATTERNtoPRE_RELEASE_PATTERNand broadening it to matchbNas well asrcN, soremove_old_releasesalso cleans up old beta directories.dev/breeze/doc/09_release_management_tasks.rstand the beta section ofREADME_RELEASE_AIRFLOW.mddocument the flow. Tests cover the version/branch handling, the branch-tip checkout, the pattern, and the beta-dir cleanup.Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.8) following the guidelines