| name | Publish New Version |
| description | Bumps version and triggers a new Lumi release via GitHub Actions |
Publish New Version
When the user asks to publish or release a new version of Lumi:
- Check current version: Read the
<Version> tag in src/Lumi/Lumi.csproj
- Determine new version: Bump the patch version (e.g., 0.1.0 → 0.2.0), or ask the user if they want a specific version
- Update csproj: Edit the
<Version> tag in src/Lumi/Lumi.csproj to the new version
- Generate changelog:
- Get the commit diff since the last release tag:
git log <last-tag>..HEAD --oneline
- Read the raw commit messages and infer user-facing changes
- Write a human-readable changelog in markdown with these sections (omit empty sections):
- ✨ New Features — new capabilities, UX additions
- 🐛 Bug Fixes — resolved issues
- 🔧 Improvements — polish, performance, refactors that affect UX
- Each entry should be a concise, user-friendly sentence (not a commit message). Group related commits into a single entry when appropriate.
- Save the changelog text — it will be used as the GitHub Release body.
- Commit and push:
git add src/Lumi/Lumi.csproj
git commit -m "bump version to X.Y.Z"
git push origin main
- Trigger release workflow:
gh workflow run release.yml -f version=X.Y.Z
- Monitor the build:
gh run list --workflow="release.yml" -L 1
gh run watch <run-id> --exit-status
- Update the release with changelog: Once the workflow completes, update the release body:
gh release edit vX.Y.Z --notes "<changelog markdown>"
- Verify: Confirm the release is published with the changelog:
gh release view vX.Y.Z
Important Notes
- The version must be valid SemVer (e.g., 1.0.0, 0.2.0)
- The release workflow builds for Windows x64, signs with Azure Trusted Signing (sign CLI), and publishes to GitHub Releases
- The
gh CLI must be authenticated (gh auth status)
- Always bump version in csproj BEFORE triggering the workflow
- The changelog should describe what changed from the user's perspective, not implementation details
