| name | publish-release |
| description | Publish a new version of `KlutzyNinja.Touki` or `KlutzyNinja.Touki.TestSupport` to NuGet by cutting a release tag. Use when asked to "publish a new version", "release alpha.N", "ship a beta", "cut a release", "promote alpha to beta", or "tag and publish". Walks the user through choosing the right `Major.Minor.Patch` bump, deciding whether to stay in `alpha` / `beta` / `rc` / stable, picking the correct tag stream (`v*` vs `ts-v*`), pushing the tag, and creating the matching GitHub release. Vets when an `AssemblyVersion`-changing bump is required (binary breaking changes vs additive/bugfix work). |
| metadata | {"applicability":"repo-local","binding":"none","maturity":"stable","portability":"repo-specific","related":"create-pr","requires":"pre-pr-self-review","risk":"remote-write"} |
Publish a release
This repo ships two NuGet packages from independent tag streams:
MinVer derives every version artifact
(Version, PackageVersion, AssemblyVersion, FileVersion,
InformationalVersion) from the tag at HEAD. The tag is the version.
MinVer is wired in Directory.Build.targets
gated on IsPackable != 'false'; per-project <MinVerTagPrefix> overrides
live in touki.testsupport/touki.testsupport.csproj.
The publish workflow only fires when the tag is pushed. Both workflows have a
regex guard that rejects malformed tags (e.g. the historical v.0.1.0-alpha.11
typo) before any pack/push runs.
Approval scope. "Publish a release" authorizes preparing the tag and
release notes. It does not authorize the tag push. The
Approval checkpoint below is the gate. See AGENTS.md
section "Working with the user on changes" for the canonical rule.
Steps overview
- Inspect repo state and confirm the package (below).
- Establish the prior version on the stream - see versioning.md.
- Decide the prerelease channel (alpha / beta / rc / stable) - versioning.md.
- Decide
Major.Minor.Patch and check the AssemblyVersion gotcha - versioning.md.
- Compose and validate the tag against the workflow regex - versioning.md.
- Approval checkpoint (below) - stop and wait for an explicit publish verb.
- Create and push the tag, then watch the workflow - see release-steps.md.
- Create the GitHub release from the notes template - release-steps.md.
- Aftercare (sample version bump, TestSupport lockstep) - release-steps.md.
1. Inspect repo state and confirm the package
Read-only checks:
git remote -v - confirm origin points at JeremyKuhne/touki (push
target).git rev-parse --abbrev-ref HEAD - must be main or a release branch.
Refuse to tag from an arbitrary feature branch unless the user explicitly
says so.git status --porcelain - must be clean. If dirty, stop and ask.git log origin/main..HEAD and git log HEAD..origin/main - must both be
empty. Tag must point at the published origin/main tip (or whatever the
user confirmed in the previous bullet).
Ask the user which package if not already obvious from the request:
KlutzyNinja.Touki - the main library.KlutzyNinja.Touki.TestSupport - test helpers. Released only when
touki.testsupport/ code changed or the Touki release is a binary break;
see versioning.md "TestSupport releases: when and what
version".
Use vscode_askQuestions only if ambiguous; if the user said "publish
TestSupport" or similar, skip the prompt.
Then work through steps 2-5 in versioning.md to land on a
validated tag.
Approval checkpoint
Stop here. Show the user:
- The chosen tag (e.g.
v0.1.0-alpha.13).
- The prior tag and what bumped (e.g. "alpha.12 -> alpha.13, no Major/Minor
change").
- The commit the tag will point at (
git rev-parse HEAD, short SHA + subject).
- A short summary of the changes since the prior tag (
git log --oneline <prior-tag>..HEAD).
- The expected published
AssemblyVersion before/after.
Wait for an explicit publishing verb (tag, push the tag, ship it,
publish). Do not infer approval from the original "publish a release"
request - that authorized the preparation, not the push. See AGENTS.md.
After approval, follow release-steps.md to push the tag,
watch the workflow, and create the GitHub release.
Sub-pages
- versioning.md - establishing the prior version, the
prerelease channel decision, the
Major.Minor.Patch bump table, the
AssemblyVersion gotcha, the exact tag format with its regex guard, and
when TestSupport warrants a release of its own.
- release-steps.md - creating and pushing the annotated
tag,
workflow_dispatch recovery, the GitHub release notes template, and
aftercare.
Cross-references
