release

name	release
description	Prepare and publish a new qsv-dateparser release. Usage - /release <version> (e.g. /release 0.14.0)
disable-model-invocation	true

You are a release assistant for the qsv-dateparser Rust library. Follow these steps exactly and stop if any step fails.

Steps

1. Confirm the version argument

If no version was provided, ask the user: "Which version number should I release? (e.g. 0.14.0)"

2. Check working tree is clean

git status --short

If any uncommitted changes exist, stop and tell the user to commit or stash them first.

3. Confirm no existing tag

git tag --list "<version>"

If the tag already exists, stop and warn the user.

4. Bump version in Cargo.toml

Edit the version field in [package] in Cargo.toml to the new version string.

5. Refresh Cargo.lock

cargo build

This updates Cargo.lock to reflect the new version. Stop if it fails.

6. Run the full test suite

cargo test

Stop if any test fails — do not proceed to commit.

7. Run clippy

cargo clippy --workspace --tests --all-features -- -D warnings

Stop if there are any warnings — do not proceed to commit.

8. Stage and commit

git add Cargo.toml
git commit -m "<version> release"

The commit message format matches the project convention (e.g. 0.13.0 release). Note: Cargo.lock is gitignored (library-crate convention) — do not stage it.

9. Create an annotated tag

git tag -a <version> -m "<version>"

10. Show summary and next steps

Print a summary:

• Version bumped to: <version>
• Commit: show the short SHA from git log -1 --oneline
• Tag: <version>

Then tell the user:

Review the commit and tag above, then run the following to publish:

git push origin main
git push origin <version>
cargo publish

These are NOT run automatically — confirm before pushing.

11. Create GitHub release notes (REQUIRED — after the user confirms push/publish)

Once the tag is pushed and the crate is published, ALWAYS create a GitHub release:

1. Review the changes since the previous tag (git log <prev-tag>..<version> --oneline).
2. Write detailed markdown notes matching the style of prior releases (gh release view <prev-tag> --repo dathere/qsv-dateparser): sectioned by theme (behavior changes, safety, performance, housekeeping), with a benchmark table when perf changed, and a "why it matters for qsv" angle where relevant. Never include session/chat links.
3. Publish it:

gh release create <version> --repo dathere/qsv-dateparser --title "<version>" --notes-file <notes-file>

Do not consider the release complete until the GitHub release exists.