release

Release

Automate the full KernSmith release workflow from version bump through PR merge.

Important

Run all git commands directly (e.g., git status) without prefixing cd <path> &&. The Bash tool already runs in the project's working directory, and the cd prefix breaks permission allow-list matching on Bash(git *).

Input

$ARGUMENTS should be the version number (e.g., 0.10.4). If not provided, read the current version from Directory.Build.props and ask the user what the new version should be.

Steps

1. Validate and prepare

# Get current version for reference
grep '<Version>' Directory.Build.props
# Make sure we're starting clean
git status

If there are uncommitted changes, warn the user and stop — don't proceed with dirty working tree.

2. Branch from latest main

git checkout main
git pull
git checkout -b version/<version>

3. Bump version

Edit Directory.Build.props — change <Version>X.Y.Z</Version> to the new version. This is the single source of truth; all projects inherit it.

4. Update CHANGELOG.md

Move everything under ## [Unreleased] into a new version section. The result should look like:

## [Unreleased]

## [<version>] - <today's date YYYY-MM-DD>

### Added
- (entries that were under Unreleased)

### Fixed
- (entries that were under Unreleased)

If [Unreleased] is empty, add a single entry: - Version bump and documentation updates

5. Update RELEASING.md

Update any version number examples in RELEASING.md to use the new version (e.g., command-line examples, tag examples). These are illustrative — keep them current so the doc stays useful.

6. Documentation audit

Spawn an Explore agent to check whether all documentation layers are consistent with the current codebase. The agent should check:

• XML doc comments: Do all public methods/types added since the last release have <summary> tags?
• Root README.md: Does the features list reflect current capabilities?
• Feature comparison (COMPARISON.md): Do the KernSmith feature columns and — especially — the rasterizer backend capability table match the code? Verify every backend claim (color fonts, variable fonts, SDF, outline stroke, synthetic bold/italic, anti-aliasing modes, system fonts) against the IRasterizerCapabilities implementations (src/KernSmith.Rasterizers.*/*Capabilities.cs and FreeTypeRasterizer.cs) — do NOT assume; these tables have drifted from the code before (e.g. color/variable-font rows were once inverted between FreeType and DirectWrite). Also check the two capability tables agree with each other.
• CLI README (tools/KernSmith.Cli/README.md): Are all CLI commands and flags documented?
• UI README (apps/KernSmith.Ui/README.md): Does the feature list match current UI?
• DocFX docs (docs/): Are doc pages consistent with the code?
• Reference docs (reference/): Any stale references?
• NuGet descriptions: Do .csproj <Description> fields reflect current package capabilities?