From 6fb8d47da449a7b05aec62e71284fc5a4ce3afd5 Mon Sep 17 00:00:00 2001 From: acx10 Date: Thu, 22 Jan 2026 01:06:14 -0700 Subject: [PATCH] Fix RC flow --- .github/RELEASE_WORKFLOW.md | 20 ++++++++++++++++++++ .github/workflows/release-pipeline.yml | 4 ++-- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/.github/RELEASE_WORKFLOW.md b/.github/RELEASE_WORKFLOW.md index 48b27b5ef..713cc45b2 100644 --- a/.github/RELEASE_WORKFLOW.md +++ b/.github/RELEASE_WORKFLOW.md @@ -179,6 +179,26 @@ gh pr merge --squash - Each merge to `release/1.18` publishes a new RC (`v1.18.0-rc.2`, `rc.3`, etc.) - Testers can pull specific RC versions to validate fixes +**Recommended: Keep `develop` in sync** + +To avoid `develop` having stale/buggy code until the release completes, create PRs targeting both branches: + +```bash +git checkout release/1.18 +git checkout -b fix/critical-bug +# ... make fixes ... +git commit -m "Fix critical bug in authentication" +git push -u origin fix/critical-bug + +# Create PR for release branch +gh pr create --base release/1.18 --title "Fix critical bug" + +# Create PR for develop (same branch, different target) +gh pr create --base develop --title "Fix critical bug" +``` + +Both PRs can be reviewed and merged independently. When `master` is merged back to `develop` in Phase 5, Git will recognize the identical changes and resolve cleanly. + --- ### Phase 3: Merge to Master diff --git a/.github/workflows/release-pipeline.yml b/.github/workflows/release-pipeline.yml index ae0171cef..0f48bacbf 100644 --- a/.github/workflows/release-pipeline.yml +++ b/.github/workflows/release-pipeline.yml @@ -246,8 +246,8 @@ jobs: rc_number=$(git rev-list --count HEAD 2>/dev/null || echo "1") fi - # Ensure RC number is at least 1 - rc_number=$((rc_number > 0 ? rc_number : 1)) + # Convert commit count to RC number (0 commits = rc.1, 1 commit = rc.2, etc.) + rc_number=$((rc_number + 1)) rc_tag="v${full_version}-rc.${rc_number}" short_sha=$(git rev-parse --short HEAD)