Also known as: semantic versioning "SemVer"
Semantic versioning (SemVer) is a MAJOR.MINOR.PATCH numbering convention in which
the version number itself communicates the nature of each change — breaking,
backward-compatible feature, or bug fix.1
The rules
Under SemVer you bump exactly one part of the version per release, by the nature of the change:
| Bump | When | Example |
|---|---|---|
| PATCH | Backward-compatible bug fix | 1.4.2 → 1.4.3 |
| MINOR | Backward-compatible new feature | 1.4.3 → 1.5.0 |
| MAJOR | Breaking, backward-incompatible change | 1.5.0 → 2.0.0 |
A user reading 1.5.0 → 1.5.1 knows it is a safe update; 1.x → 2.0 warns them to read
the release notes. Pre-1.0.0 versions are treated as unstable, and suffixes like
-rc.1 or -beta mark pre-releases. That single convention prevents a great deal of
confusion about whether an upgrade is safe.1
Why it matters
SemVer turns a version string into a contract about compatibility, which is what makes automated dependency management possible: a manifest can safely request “compatible with 1.4” and let the resolver accept newer 1.x releases but not a breaking 2.0. The “breaking change” that triggers a MAJOR bump is precisely a change to a published API — its operations, types, or behavior — so SemVer and good API design go hand in hand.
In practice
A release is usually a tagged commit in version control, and a CI/CD pipeline often builds and publishes the versioned artifacts automatically when a tag is pushed. The version baked into the build and printed by the program lets users and maintainers identify exactly which release they are running.2
Sources
-
Semantic Versioning 2.0.0 — the authoritative SemVer specification defining MAJOR.MINOR.PATCH and pre-release suffixes. ↩ ↩2
-
Software versioning — Wikipedia, for versioning schemes and release-tagging practice. ↩