Releasing

Nyzhi releases are triggered by Git tags and automated through GitHub Actions. A single tag push builds binaries for four platforms, publishes to crates.io and npm, and creates a GitHub release.

Triggering a Release

Push a version tag:

git tag v1.2.9
git push origin v1.2.9

The release workflow triggers on any tag matching v*.

Version Source

The canonical version lives in the workspace manifest:

# Cargo.toml
[workspace.package]
version = "1.2.9"

The workflow strips the v prefix from the tag to derive the publish version.

Pipeline Stages

The release pipeline runs in sequence:

1. Build Matrix

Builds binaries for four platforms:

2. Package Artifacts

• Creates tarballs for each platform
• Generates SHA-256 checksums

3. Upload and Release

• Uploads artifacts to the CI release endpoint
• Creates a GitHub release with attached binaries

4. Publish to crates.io

Crates are published in dependency order:

1. nyzhi-config
2. nyzhi-auth
3. nyzhi-index
4. nyzhi-provider
5. nyzhi-core
6. nyzhi-tui
7. nyzhi (CLI)

5. Publish to npm

Platform-specific packages plus an umbrella package:

The workflow:

1. Extracts the platform binary into each package
2. Sets the package version to match the tag
3. Publishes platform packages
4. Updates the umbrella’s optionalDependencies
5. Publishes the umbrella package

Pre-Release Checklist

Before tagging a release:

# 1. Run all quality checks
cargo fmt --all --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace

# 2. Verify workspace version is updated
grep '^version' Cargo.toml

# 3. Verify npm package metadata matches
cat npm/nyzhi/package.json | grep version

# 4. Review changelog / release notes

# 5. Tag and push
git tag v1.2.9
git push origin v1.2.9

Required Secrets

The release workflow needs these GitHub repository secrets:

Next Steps

• Building from Source — local builds and cross-compilation
• Self-Update — how users receive updates