release

Release a new version of toki. macOS binaries are built locally, Linux binaries are built via GitHub Actions.

Instructions

When the user runs /release, follow these steps:

1. Determine version

• Ask the user for the version to release (e.g., 2.3.0)
• Or if the user already provided it as an argument (e.g., /release 2.3.0), use that
• Validate it follows semver format (MAJOR.MINOR.PATCH or MAJOR.MINOR.PATCH-prerelease)

2. Pre-flight checks

• Run cargo test to make sure tests pass
• Run cargo clippy --all-targets --all-features -- -D warnings. The current development branch has a warning baseline, so this strict release gate is expected to block until those warnings are resolved; do not mistake plain Clippy's exit 0 for a clean release check.
• Check git status to ensure the working tree is clean (no uncommitted changes)
• Check that the tag v{VERSION} doesn't already exist: git tag -l v{VERSION}
• Confirm Cargo.toml has no local [patch."https://github.com/korjwl1/toki-sync-protocol.git"] section. A tagged release/Actions checkout has no sibling ../toki_sync_protocol, so releasing with the patch is guaranteed to fail.
• Confirm the protocol dependency is pinned to a published tag containing every wire type the client uses. The current baseline is toki-sync-protocol v1.1.0; release toki-sync before consumers when a future protocol change adds server capabilities.

If any check fails, report the issue and stop.

3. Update version

• Update version in Cargo.toml to the new version
• Run cargo check to update Cargo.lock
• Commit with message: chore: bump version to {VERSION}

4. Build macOS targets (local)

cargo build --release --target aarch64-apple-darwin
cargo build --release --target x86_64-apple-darwin

Package into tar.gz:

for target in aarch64-apple-darwin x86_64-apple-darwin; do
  tar -czf "toki-{VERSION}-${target}.tar.gz" -C "target/${target}/release" toki
done

5. Create tag, push, and upload