chore(versioning): add release/v11 to publicReleaseRefSpec#290
Merged
ChrisonSimtian merged 1 commit intoMay 29, 2026
Merged
Conversation
3 tasks
ChrisonSimtian
added a commit
that referenced
this pull request
May 29, 2026
Branch protection on `release/v11` (applied in #270) requires the `ubuntu-latest` status check, but `.github/workflows/ubuntu-latest.yml` and `.github/workflows/ubuntu-latest-docs.yml` only fired on PRs targeting `main`. Net effect: PRs against `release/v11` had no CI and got BLOCKED by branch protection waiting for a check that never reported — a chicken-and-egg that surfaced when #290 (the NB.GV publicReleaseRefSpec tweak) couldn't merge. Changes: - Both workflows now list `main` AND `release/v*` under `pull_request.branches:`. - `build/Build.cs` gains a `ReleaseBranchPattern = "release/v*"` constant alongside `MainBranch`. - `build/Build.CI.GitHubActions.cs` extends `OnPullRequestBranches` on the ubuntu-latest `[GitHubActions]` attribute to include both branches, so next time the auto-generator runs it produces the same YAML. Out of scope: `windows-latest` and `macos-latest` stay `OnPushBranches` only (post-merge / release validation). They run after merge regardless of base branch via the push trigger. After this lands on main, the same workflow files need to be brought across to `release/v11` (separate PR — same chicken-and-egg until release/v11 also has the updated workflows; will be admin-bypass-merged once). Refs milestone #13. Unblocks #290. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ChrisonSimtian
added a commit
that referenced
this pull request
May 29, 2026
Branch protection on `release/v11` (applied in #270) requires the `ubuntu-latest` status check, but `.github/workflows/ubuntu-latest.yml` and `.github/workflows/ubuntu-latest-docs.yml` only fired on PRs targeting `main`. Net effect: PRs against `release/v11` had no CI and got BLOCKED by branch protection waiting for a check that never reported — a chicken-and-egg that surfaced when #290 (the NB.GV publicReleaseRefSpec tweak) couldn't merge. Changes: - Both workflows now list `main` AND `release/v*` under `pull_request.branches:`. - `build/Build.cs` gains a `ReleaseBranchPattern = "release/v*"` constant alongside `MainBranch`. - `build/Build.CI.GitHubActions.cs` extends `OnPullRequestBranches` on the ubuntu-latest `[GitHubActions]` attribute to include both branches, so next time the auto-generator runs it produces the same YAML. Out of scope: `windows-latest` and `macos-latest` stay `OnPushBranches` only (post-merge / release validation). They run after merge regardless of base branch via the push trigger. After this lands on main, the same workflow files need to be brought across to `release/v11` (separate PR — same chicken-and-egg until release/v11 also has the updated workflows; will be admin-bypass-merged once). Refs milestone #13. Unblocks #290. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per NB.GV validation (#275 finding), release/v11 was producing git-sha-suffixed versions like `11.0.19-g4b19a8c1` instead of clean `11.0.19` because the branch wasn't in `publicReleaseRefSpec`. With #274 about to make tag-triggered releases fire from this branch, the suffix would land on nuget.org under what looks like a clean v11.0.X tag — confusing for consumers and not what the tag implies. Adds `^refs/heads/release/v11$` to publicReleaseRefSpec. This branch now produces clean version strings on commits + tag heights. Lands directly on release/v11 (not main) because: - main is still 11.0 and adding release/v11 to main's publicReleaseRefSpec would create a height collision (both branches public-mapped to the same version). - The setting is intentionally branch-specific to how release/v11 generates versions — not something that needs to propagate forward to main / future release/v12. main's publicReleaseRefSpec is unchanged. When #271 lands and bumps main to 12.0, the equivalent edit will happen on release/v12 (or whatever the next major's release branch is named). Refs #275, milestone #13. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ChrisonSimtian
force-pushed
the
chore/release-v11-public-release-refspec
branch
from
May 29, 2026 07:08
6e89d68 to
7bcf2cc
Compare
7 tasks
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
1 participant
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.
Targets
release/v11(not main). Closes #275.Problem
Per the NB.GV validation under #275,
release/v11was producing git-sha-suffixed versions like11.0.19-g4b19a8c1instead of clean11.0.19because the branch wasn't inpublicReleaseRefSpec. With #274 (the tag-triggered shape) about to land, the firstv11.0.Xtag would publish to nuget.org with the suffix in the version string — confusing for consumers and not what the tag implies.Fix
Adds
^refs/heads/release/v11$topublicReleaseRefSpecinversion.json. Commits + tag heights on this branch now produce clean version strings.Why it targets release/v11 and not main
mainis still at11.0(issue Bump main's version.json to 12.0 (next-major trunk) #271, "bump main to 12.0", is deferred until v12 work actually starts).release/v11tomain'spublicReleaseRefSpecwhile both branches have"version": "11.0", NB.GV would treat both as public-release branches for the same major+minor — patch-height collisions follow.12.0, the equivalent edit will happen on whatever next release branch is cut.Verification (you can spot-check post-merge)
Test plan
nbgv get-versionon release/v11 produces clean output.🤖 Generated with Claude Code