Semantic Versioning
In short
Semantic versioning is a MAJOR.MINOR.PATCH numbering scheme in which each part signals whether a release breaks compatibility, adds features, or fixes bugs.
What is semantic versioning?
Semantic versioning, often shortened to SemVer, gives software releases version numbers that carry meaning. A version like 2.4.1 has three parts: the major version (2), the minor version (4), and the patch version (1). Just by comparing two version numbers, developers can tell how risky an upgrade is likely to be.
The rules are simple. Increase the patch number for backward-compatible bug fixes, the minor number for new features that don't break existing code, and the major number for breaking changes that may require users to update their code. When a higher part increases, the lower parts reset to zero, so after 2.4.1 a new feature release is 2.5.0 and a breaking release is 3.0.0. Versions starting with 0, such as 0.9.2, signal early development, where anything may change at any time.
Semantic versioning works like a warning label on an update: a patch is a quiet repair, a minor release adds something new without moving anything, and a major release may rearrange things you depend on. Package managers rely on it heavily. In npm's package.json, a range like ^2.4.1 accepts any 2.x version from 2.4.1 upward, while ~2.4.1 accepts only newer patches of 2.4, and releases are often marked in Git with tags like v2.4.1.
SemVer is a promise made by people, not something tools enforce, so a release can still break things by mistake. It is also different from calendar versioning, used by projects such as Ubuntu (for example, 24.04), where the numbers reflect the release date rather than compatibility. Pre-release versions add a label after a hyphen, such as 3.0.0-beta.1, and are considered lower than the final 3.0.0.
Key takeaways
- Versions follow the MAJOR.MINOR.PATCH format, such as
2.4.1. - Bump MAJOR for breaking changes, MINOR for new compatible features, and PATCH for bug fixes.
- Lower numbers reset to zero when a higher one increases.
0.xversions mean the public API is not yet stable.- npm ranges like
^and~use SemVer to decide which updates are safe to install.
Example
# Mark a release in Git with a version tag
git tag -a v2.4.1 -m "Fix crash on empty cart"
git push origin v2.4.1
# Let npm bump the version in package.json and create the tag
npm version patch # 2.4.1 -> 2.4.2 (bug fix)
npm version minor # 2.4.2 -> 2.5.0 (new feature)
npm version major # 2.5.0 -> 3.0.0 (breaking change)
# How dependency ranges in package.json read:
# "^2.4.1" allows >=2.4.1 <3.0.0
# "~2.4.1" allows >=2.4.1 <2.5.0Readers ask
What is a breaking change?
A breaking change is any change that can make existing code that uses the software stop working, such as removing a function, renaming an option, or changing what a function returns. Under semantic versioning, a breaking change requires a new major version.
What does the caret (^) mean in package.json?
A caret range such as ^2.4.1 lets npm install any later version with the same major number, so 2.9.0 is allowed but 3.0.0 is not. For 0.x versions it is stricter: ^0.4.1 allows only 0.4.x patches.
What does version 1.0.0 mean?
In semantic versioning, 1.0.0 is the first release with a stable public API. Before that, 0.x versions are for initial development, and breaking changes can happen in any release.
See also
- GitVersion Control, p. 10Git is a free, open-source distributed version control system that tracks changes to files over time, so developers can collaborate and undo mistakes.
- CommitVersion Control, p. 5A commit is a saved snapshot of a project's files in Git, recorded with a unique ID, an author, a timestamp, and a message describing what changed.
- APIBackend & APIs, p. 2An API is a set of rules that lets one piece of software request data or actions from another in a predictable, documented way.
- CI/CDDevOps & Cloud, p. 9CI/CD is a set of automated practices that build, test, and release code changes frequently, so software can be delivered to users quickly and safely.
- MonorepoVersion Control, p. 31A monorepo is a single version control repository that holds the code for many projects, such as several apps, services, and shared libraries, managed together.
- Conventional CommitsVersion Control, p. 6Conventional Commits is a specification for structured commit messages like feat: add search, so tools can write changelogs and pick versions automatically.
Spotted a mistake or something missing on this page?Suggest an edit