Skip to main content

Semantic Versioning

Updated 2 min read

Share this page

Send the link, quote the definition with a link back, or show it as a card on your own site.

https://softwaredictionary.org/terms/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.x versions mean the public API is not yet stable.
  • npm ranges like ^ and ~ use SemVer to decide which updates are safe to install.

Example

Tagging and bumping versionsbash
# 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.0

Readers 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

Spotted a mistake or something missing on this page?Suggest an edit

Read a random page
Open today's review
Switch to the dark theme
Read this page in Türkçe

More

Settings