Conventional Commits and Semantic Versioning
feat, fix, BREAKING CHANGE and MAJOR.MINOR.PATCH: two conventions that, combined, automate the changelog and the version number.
Conventional Commits: the structure
<type>(<optional scope>): <description> [optional body] [optional footer, e.g. BREAKING CHANGE: ...]
feat(cart): add removing an item fix(auth): fix token expiring too early docs: update the install README
Common types
| Type | Use |
|---|---|
feat |
A new feature |
fix |
A bug fix |
docs |
Documentation only |
refactor |
Code change with no new feature or fix |
test |
Adding/changing tests |
chore |
Miscellaneous tasks (config, dependencies…) |
perf |
Performance improvement |
Semantic Versioning (SemVer)
MAJOR . MINOR . PATCH → 2.4.1
| Part | Bumps when |
|---|---|
| MAJOR | Incompatible change vs previous versions |
| MINOR | Backwards-compatible new feature |
| PATCH | Backwards-compatible bug fix |
With well-written feat/fix/BREAKING CHANGE commits, tools like semantic-release automatically compute the next version number and generate the changelog.
Pre-releases and ranges
1.4.0-beta.1 " pre-release ^1.4.0 " compatible with 1.x.x (as long as MAJOR doesn't change) ~1.4.0 " compatible with 1.4.x only
Signalling a breaking change
feat(api)!: rename the "id" parameter to "userId" BREAKING CHANGE: the `id` query parameter no longer exists, use `userId`.
A ! after the type/scope and/or a BREAKING CHANGE: footer automatically trigger a MAJOR version bump with automated release tools.
Thanks for the feedback!