Semantic Versioning
After making code changes, determine whether a version bump is required and which component to increment.
Version Format: MAJOR.MINOR.PATCH
PATCH (X.Y.Z -> X.Y.Z+1)
Increment for changes that do not affect the public API:
- Bug fixes and minor corrections
- Performance improvements
- Documentation updates
- Internal refactoring
MINOR (X.Y.Z -> X.Y+1.0)
Increment for backward-compatible additions:
- New features
- New CLI commands or options
- New public API surface
Reset PATCH to 0 when incrementing MINOR.
MAJOR (X.Y.Z -> X+1.0.0)
Increment for breaking changes:
- Removal of features or commands
- Incompatible API changes
- Changes that require user action or code updates
Reset MINOR and PATCH to 0 when incrementing MAJOR.
Process
- Review the changes made
- Classify the change using the guide in
shared/commit-conventions.md - Find the current version in the project manifest (e.g.
Cargo.toml,package.json) - Map the classification to a version bump (see below)
- Increment the appropriate version component
- Include the version bump in the same commit as the code change
- Mention the version bump in the commit message footer if significant
Do not create a separate commit for the version bump. It belongs with the change that caused it.
Classification to Version Bump
| Classification | Bump |
|---|---|
| Non-breaking fix, refactor, docs, perf | PATCH |
| Non-breaking feature | MINOR |
| Breaking change | MAJOR |