chore(release): stage clean 10.3.48 marker on release/v10.3 - #296
Merged
Conversation
release/v10.3 is parked at the last clean commit (#170 == git-height 23, i.e. 10.3.23 code). The contaminated 10.3.24-47 patches are being unlisted from nuget.org. This stages a fresh CLEAN marker above them: - versionHeightOffset: 24 -> height 24 (this commit) + 24 = patch 48 - publicReleaseRefSpec gains ^refs/heads/release/v10.3$ so a build ON release/v10.3 is a STABLE public release (10.3.48), not a -preview. No publish here. The actual 10.3.48 push to nuget.org is a separate operation with a push-scoped key. VERIFY before publishing: 'nbgv get-version' on release/v10.3 must report 10.3.48 (NOT 10.3.25 — which would mean the offset reset height and collide with a contaminated version). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Wires release/v10.3's release workflow to fire on push to the branch (was push:main, which never triggers here) plus manual dispatch, and binds it to the nuget-org Environment so the env-scoped NUGET_API_KEY (#273) resolves and the required-reviewer approval gate runs before any nuget.org push. Merging this PR is the inaugural release-from-release/vN run: it builds the clean #170 code as the stable 10.3.48 marker and publishes it. Keeps the #170-era './build.cmd Test Pack Publish' invocation (local 'dotnet fallout' tool didn't exist until #204, after this branch point). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Closed
4 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.
Stages a fresh clean
10.3.48marker onrelease/v10.3, to sit above the contaminated10.3.24–10.3.47patches being unlisted from nuget.org.What & why
release/v10.3is parked at the last clean commit (44770a6a, #170 = git-height 23 =10.3.23code). After unlisting.24–.47, the highest listed version would fall back to10.3.23. This publishes a fresh, blessed clean marker on top instead.version.json:versionHeightOffset: 24→ height 24 (this commit) + 24 = patch 48publicReleaseRefSpecgains^refs/heads/release/v10\.3$so a build onrelease/v10.3is a stable public release (10.3.48), not a-preview.Run
nbgv get-versiononrelease/v10.3after merge and confirm it reports10.3.48. If it reports10.3.25, the offset reset the git-height (would collide with a contaminated version) — stop and adjust the offset.Not in scope
No publish. The
10.3.48push to nuget.org is a separate manual step with a push-scoped key (the key used for the unlist is unlist-only). The #170-erarelease.ymltriggers on push tomain, so the marker publish is a deliberate manualPack+Publishfromrelease/v10.3.🤖 Generated with Claude Code