| name | publish-release |
| description | Publish a new version of the `KlutzyNinja.Madowaku` NuGet package 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 through choosing the right `Major.Minor.Patch` bump, deciding whether to stay in `alpha` / `beta` / `rc` / stable, composing the `v*` tag, pushing it, and creating the matching GitHub release. Flags when an `AssemblyVersion`-changing Major bump is required (binary breaking changes vs additive/bugfix work). |
| argument-hint | Describe the release you want to cut (channel and/or version bump) if known. |
Publish a release
This repo ships a single NuGet package from one tag stream:
MinVer derives every version artifact
(Version, PackageVersion, AssemblyVersion, FileVersion,
InformationalVersion) from the tag at HEAD. The tag is the version.
MinVer is referenced directly in
madowaku/madowaku.csproj with
<MinVerTagPrefix>v</MinVerTagPrefix>; there is no Directory.Build.targets
and no per-project override (only one package ships).
The publish workflow fires when a v*.*.* tag is pushed. It can also publish an
existing tag through workflow_dispatch after a transient or authentication
failure. publish.yml validates the tag
against a SemVer-with-v-prefix regex as its first step, so a malformed tag such
as v.0.1.0-alpha.3 fails fast before any pack/push. The v*.*.* trigger glob
is not the guard — it matches the stray dot too; the validation step is
what stops a typo. See the "Tag-format guard" section in
versioning.md.
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 § "Working with the user on changes" for
the canonical rule.
Steps overview
- Inspect repo state (below).
- Establish the prior version — 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 — 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 — release-steps.md.
1. Inspect repo state
Read-only checks:
git remote -v — confirm origin points at JeremyKuhne/madowaku
(the 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. The tag must point at the published origin/main tip (or whatever
the user confirmed in the previous bullet).
There is only one package, so no "which package" prompt is needed. 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.4).
- The prior tag and what bumped (e.g. "alpha.3 → alpha.4, 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, and the tag-format guard.
- release-steps.md — creating and pushing the
annotated tag,
workflow_dispatch recovery, the GitHub release notes
template, and aftercare.
Cross-references
