Conventional Commits and SemVer

Conventional Commits is a commit-message format that machines can parse: a type(scope): description first line plus optional footers. Semantic Versioning is a numbering contract, MAJOR.MINOR.PATCH, that tells consumers what a version bump means. Together they let tooling derive the next version and the changelog directly from your commit history.

The payoff is that releases stop being a manual judgment call. Once every commit declares its kind, a tool can read the log, decide whether the change is a patch, a feature, or a break, tag the version, and write the notes — no human deciding "is this a minor or a major?"

The Conventional Commits Format

The first line is a type, an optional scope in parentheses, and a short description. Common types are feat, fix, chore, and docs. A breaking change is flagged with a ! after the type or a BREAKING CHANGE: footer in the body.

feat(auth): add OAuth login

BREAKING CHANGE: removes the legacy token endpoint

The structure is the whole point — a parser can read the type and the breaking-change marker without understanding the prose, which is what makes the downstream automation possible.

Semantic Versioning Rules

SemVer maps change kinds to version components: a fix bumps the patch number, a feat bumps the minor, and a breaking change bumps the major. A major bump is a promise to consumers that something they depend on has changed in an incompatible way.

That promise runs both directions. Bumping major when nothing broke tells everyone to brace for a migration that does not exist; leaving it at minor when something did break sends the break out silently.

Deriving Versions Automatically

Because the mapping is mechanical, tooling can compute the next version from the commits since the last release: any feat means at least a minor, any breaking change means a major, otherwise a patch. The one caveat is 0.x — under SemVer, anything below 1.0.0 is allowed to break in a minor bump, so the usual guarantees do not yet apply.

Automated Changelogs and Releases

Tools like semantic-release and release-please read the commit history, decide the version, tag it, and generate release notes grouped by type. The changelog becomes a byproduct of how you already commit, not a document someone maintains by hand and forgets to update.

Enforcement

None of this works if half the team forgets the format. A commitlint check in a commit-msg hook, or a required PR-title check, makes the convention non-optional — malformed messages are rejected before they reach main, so the automation never silently skips a change.