// Cut a new vykar release: bump versions, tag, push, wait for CI, and draft release notes.
End-to-end validation suite for vykar backup tool on a Linux sandbox server
Review Rust codebases for performance anti-patterns, with emphasis on async runtimes, client-server networking, memory allocation, serialization, and concurrency. Use when asked to audit, review, or optimize Rust code for performance.
Review and improve Rust application architecture for large CLI and backup systems, including workspace layout, crate boundaries, error handling, async/sync design, and testing strategy.
Security review skill for the vykar backup tool (Rust). Use when reviewing code for security issues, auditing cryptographic implementations, checking for credential leaks, reviewing unsafe code, or validating the security model of the backup tool. Covers encryption, key management, repository integrity, hook execution, config parsing, dependency auditing, and backup-specific attack surfaces.
| name | release |
| description | Cut a new vykar release: bump versions, tag, push, wait for CI, and draft release notes. |
Release workflow for vykar. The CI pipeline lives in .github/workflows/release.yml and triggers on v* tags pushed to main. It builds binaries for Linux (x86_64), macOS (aarch64), and Windows (x86_64), then publishes a GitHub Release with the artifacts and SHA256 checksums.
Run make pre-commit first to catch formatting, clippy, and test issues before bumping versions. Fix any problems before proceeding.
Update the version field in all workspace crates and the macOS Info.plist:
crates/vykar-types/Cargo.tomlcrates/vykar-common/Cargo.tomlcrates/vykar-crypto/Cargo.tomlcrates/vykar-storage/Cargo.tomlcrates/vykar-protocol/Cargo.tomlcrates/vykar-core/Cargo.tomlcrates/vykar-cli/Cargo.tomlcrates/vykar-server/Cargo.tomlcrates/vykar-gui/Cargo.tomlcrates/vykar-gui/macos/Info.plist (update both CFBundleVersion and CFBundleShortVersionString)Run cargo check to regenerate Cargo.lock with the new versions.
Commit the version bump (include any other pending changes that should ship). Create a git tag v<version> and push both the commit and tag to origin main. Pushing the tag triggers the release workflow.
git add <changed files> && git commit -m "Bump version to <version>"
git tag v<version>
git push origin main --tags
Use the GitHub CLI to find the triggered workflow run and watch it until all jobs complete:
gh run list --limit 5
gh run watch <run-id> --exit-status
The workflow builds on three runners (Linux, macOS, Windows), then a publish job downloads the artifacts, generates SHA256 checksums, and creates the GitHub Release via softprops/action-gh-release.
Review all commits since the previous tag:
git log <prev-tag>..v<version> --oneline --no-merges
Categorize the changes into sections (e.g. Features, Performance, Bug Fixes, Infrastructure) and update the release:
gh release edit v<version> --notes "<release notes>"
Include a downloads table at the bottom listing each platform artifact.