Single-source the version and add release.ps1 - #47
Merged
Conversation
Tagging v0.6.0 failed the release build because the csproj still said 0.5.0. Fixing it took a bump PR, a merge, and a force-moved tag. Two things made that possible: the version lived in more than one manual place, and bumping and tagging were separate acts that could happen in the wrong order. Directory.Build.props now holds the version and both projects inherit it, so neither csproj names a number and build.ps1 defaults to it rather than carrying its own. That also unsticks the shell extension, which had been stamping 0.1.0 since it was created for exactly this reason - it was a separate number nobody remembered. release.ps1 makes the ordering mistake impossible by doing the whole thing at once. It checks the branch, a clean tree, sync with origin and that the tag is free, all before writing anything, then bumps, commits, tags, and pushes the commit before the tag so the runner never sees a ref it cannot check out. release.yml reads the props file and points its error at release.ps1. It stays as a backstop rather than the thing expected to catch this. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Closes #46.
Tagging v0.6.0 failed the release build, and fixing it took a bump PR, a merge, and a force-moved tag. Two things made that possible: the version lived in more than one manual place, and bumping and tagging were separate acts that could happen in the wrong order. This removes both.
Cutting a release now
Bumps, commits, tags, pushes.
-WhatIfprints the plan without touching anything;-Branchcuts from somewhere else.One place for the version
Directory.Build.propsholds<Version>; both projects inherit it and neither csproj names a number.build.ps1defaults to it instead of carrying its own.That also unsticks
ExplorerHelper.ShellExtension, which had been stamping 0.1.0 since it was created — for exactly the reason this issue is about, it was a separate number nobody remembered. Verified after the change:The script
Preconditions all run before the first write, so a rejected release leaves the repo untouched: right branch, clean tree, in sync with origin, tag not already taken locally or on origin, and the version actually different from what's there.
It pushes the commit before the tag. A tag arriving first would start a release build against a ref the runner can't check out.
Verified
Guards, each producing its own message:
The write path was exercised for real against a throwaway bare clone acting as origin, rather than shipped untested. It bumped 0.6.0 → 0.7.0, committed, tagged, pushed both, and left a clean tree; the pushed tag resolved to the same SHA as the bump commit, and the committed diff touched only the version line.
dotnet buildon the solution passes, and./build.ps1with no arguments reportsVersion 0.6.0 (from Directory.Build.props).Docs
README's Releasing section is now the command plus what the guards do and how to recover a mis-pointed tag. CLAUDE.md gets a convention bullet, including the detail that the declared version never reaches a released binary —
build.ps1passes-p:Versionfrom the tag, which overrides it — so it only affects local builds. That is the whole reason the CI guard exists, and it wasn't written down anywhere.The guard stays, now reading the props file and pointing its error at
release.ps1. It should never fire again.🤖 Generated with Claude Code