This document outlines the release process and versioning policy for rjapi.
This project follows Semantic Versioning 2.0.0. Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backwards compatible manner
- PATCH version when you make backwards compatible bug fixes
Pre-release versions follow the format: MAJOR.MINOR.PATCH-IDENTIFIER.NUMBER
0.1.0-alpha.1- Alpha releases for early testing0.1.0-beta.1- Beta releases for wider testing0.1.0-rc.1- Release candidates for final testing
Examples of breaking changes:
- Removing or renaming public APIs
- Changing function signatures
- Modifying behavior that could break existing code
- Changing minimum supported Rust version (MSRV)
- Removing features
Examples of minor changes:
- Adding new public APIs
- Adding new optional features
- Deprecating APIs (with backwards compatibility)
- Performance improvements
- New examples or documentation
Examples of patch changes:
- Bug fixes that don't change API
- Documentation improvements
- Internal refactoring
- Dependency updates (if not breaking)
Before releasing, ensure all checks pass:
# Format code
cargo fmt --all
# Run lints
cargo clippy --all-targets --all-features -- -D warnings
# Run all tests
cargo test --all-features
# Check documentation
cargo doc --no-deps --all-features
# Verify examples work
cargo run --example basic
cargo run --example error_handling
# Dry run publish
cargo publish --dry-runUpdate version in Cargo.toml:
[package]
version = "x.y.z" # New version numberMaintain CHANGELOG.md following Keep a Changelog:
## [x.y.z] - YYYY-MM-DD
### Added
- New features
### Changed
- Changes to existing functionality
### Deprecated
- Soon-to-be removed features
### Removed
- Removed features
### Fixed
- Bug fixes
### Security
- Security fixes# Commit version bump
git add .
git commit -m "Release v0.0.2"
# Create and push tag
git tag v0.0.2
git push origin main --tags# Login to crates.io (first time only)
cargo login
# Publish
cargo publish- Update GitHub release notes
- Announce on relevant forums/social media
- Update documentation if needed
Consider using cargo-release for automation:
# Install cargo-release
cargo install cargo-release
# Perform release (patch version)
cargo release patch
# Perform release (minor version)
cargo release minor
# Perform release (major version)
cargo release majorIf a release has critical issues:
# Yank a problematic version
cargo yank --vers 0.1.0
# Un-yank if the issue was resolved
cargo yank --vers 0.1.0 --undoCurrent MSRV: 1.85.0 (required for Edition 2024)
MSRV changes are considered breaking changes and require a major version bump, except:
- During 0.x versions where minor version bumps are acceptable
- When the new MSRV is required for security updates
main- Latest stable code- Feature branches for new development
- Release tags for specific versions
All releases must pass:
- Unit tests
- Integration tests
- Documentation tests
- Examples compilation
- Clippy lints
- Format checks
- MSRV compatibility
When deprecating features:
- Mark as deprecated with
#[deprecated]attribute - Provide migration path in documentation
- Keep deprecated features for at least one major version
- Remove in next major version
Example:
#[deprecated(since = "0.2.0", note = "Use `new_function` instead")]
pub fn old_function() {
// Implementation
}Security fixes take priority and may be backported to previous versions if needed.
For critical bugs or security issues:
- Create hotfix branch from affected version tag
- Apply minimal fix
- Release patch version immediately
- Backport to main branch if needed