release-management

name	release-management
description	Use when publishing crates to crates.io, bumping versions, and managing the release pipeline. Load during the Deployment phase of SDLC.

release-management

SDLC Phase: Deployment

Release crates to crates.io, bump versions, and manage the release pipeline.

Principles

• Dependency order — Crates publish in dependency order, from leaves to root. Foundation crates first, composite crates last.
• Semantic versioning — Follow semver strictly. Breaking changes require a major version bump.
• Dry-run before publish — Always verify with a dry-run before the actual publish.
• Tag after publish — Git tags are created after successful publish, not before.

Version Bump Rules

Change Type	Version Component	Example
Breaking API change	MAJOR	1.2.3 → 2.0.0
New feature (backward-compatible)	MINOR	1.2.3 → 1.3.0
Bug fix (backward-compatible)	PATCH	1.2.3 → 1.2.4

Breaking changes include: removing a public item, changing a function signature, adding a required trait bound, altering enum variant shape.

Pre-Publish Checklist

• All workspace tests pass: cargo test --workspace
• No clippy warnings: cargo clippy --all-targets --all-features -- -D warnings
• Documentation builds without errors: cargo doc --no-deps
• Version bumped in Cargo.toml per the rules above
• Changelog updated with the new version and changes (if the project maintains one)
• cargo publish --dry-run succeeds (catches missing fields, license issues, etc.)

Publish Order

The publish order follows the dependency graph. Foundation crates with no internal dependencies publish first; leaf crates that depend on others publish last.

Typical order for rvlibs:

1. rvlibs — Shared contracts, zero dependencies
2. rvmath — Depends on rvlibs only
3. rvtest-macros — Depends on rvlibs only
4. rvtest — Depends on rvlibs, optionally on rvtest-macros
5. rvnx — Depends on rvlibs, rvmath
6. rvfx — Depends on rvnx

Path dependencies must be switched to version dependencies before publishing. Verify that each crate's Cargo.toml uses the correct version spec for workspace-internal dependencies.

Post-Publish Steps

1. Create a git tag for the release: git tag v{version}
2. Push the tag: git push origin v{version}
3. Announce the release in relevant community channels

Output Requirements

• Confirmation that each crate published successfully
• Git tag created and pushed for the release
• Summary of what changed in the release