semantic versioning (SemVer)

advancedwidespread

A numbering rule in which the three parts of a software version number reveal how significant the update is and whether it might break other programs built on the software.

In plain terms

Software version numbers often consist of three numbers, for example 2.4.1. Semantic versioning states that these numbers do not increase randomly: each position has a meaning. The first indicates a major change, after which programs built on the software may malfunction (developers call this a 'break'). The second denotes a new feature compatible with the old one, and the third indicates a bug fix.

It is like renovating an apartment. If a light bulb is replaced, it is a bug fix: you do not need to do anything differently. If a new socket is installed, it is a new possibility, but the old ones work the same way. However, if walls are moved, your furniture may not fit in the old places – this is a major version change.

It is useful because today's programs rely on countless building blocks written by others. From the version number, the developer—or the coding agent working on their behalf—can see at a glance whether an update can be safely installed or if it is better to test it thoroughly first.

An important difference compared to marketing-driven numbering: here the number does not signal how big a hit the new release is, but how cautious you need to be with it.

How it works

The version number consists of three dot-separated numbers: MAJOR.MINOR.PATCH, for example 3.2.5.
If the creators only fix a bug while everything else remains unchanged, the last number increases: 3.2.5 becomes 3.2.6.
If a new feature is added while the old ones continue to work the same way, the middle number increases and the last one resets to zero: 3.3.0.
If a change occurs that could break programs built on it, the first number increases and the other two reset to zero: 4.0.0.
Versions starting with 0 (for example, 0.9.2) indicate the initial development phase, where anything can change at any time; the hyphenated suffix (for example, 2.0.0-beta.1) denotes a pre-release, not yet final version.

An everyday example

An online store's program uses a payment component written by others that receives an update: switching from version 5.9.3 to 6.0.0. If the creators follow semantic versioning, the developer knows this is not a minor fix but a change requiring a review or even a rewrite of their own program. If only version 5.9.4 arrived, it would be a bug fix that could likely be applied without issues. This rule rarely applies to mobile app numbering, as most do not follow it.

Who is affected

developerBased on the version number, the developer decides which update can be allowed into their project automatically and which one means they should expect to rewrite code. → Code

entrepreneur, executiveA major version change in the software used by the company may involve migration costs and testing time, which should be planned in advance.

everyoneChanging the first part of a version number often signals a major transformation, but most everyday applications and browsers do not follow this rule, so conclusions drawn from their numbers should be made cautiously.

A common misconception

MythA higher version number always means better, more advanced software, while a major version change brings significant new features.

In realityThe number does not measure quality but compatibility: the major version increases when something no longer works in the old way. This can be a dramatic overhaul or even the removal of a single old feature.

Limits and risks

It is a promise, not a guarantee: nothing forces creators to number correctly, so an update labeled harmless can still cause errors.
Much well-known software does not follow this system but is numbered by date or marketing considerations, so not every three-part version number can be read this way.
The version number says nothing about security or quality: a release marked as a bug fix can contain new bugs or even malicious code.
Automatic updating, whether set up by a human or done by an agent, is reliable only when accompanied by tests, even if it relies on version numbers.

Similar, but not the same

calendar versioning (CalVer) – There, the version number shows the release date (for example, 24.04), not how much the change breaks existing behavior.
version control – Version control is a system that tracks every code modification (such as Git), while semantic versioning is only a rule for naming releases.
changelog – The changelog lists in text what changed, while the version number indicates only the scale of the change with a single triplet of numbers.

Related concepts

Broader

software versioning, software development, release management

Narrower

major version, minor version, patch version, early release

On the edge

version control, dependency management, Package manager, backward compatibility, API

A brief history

The three-part version numbering was an old developer habit, which Tom Preston-Werner, co-founder of GitHub, codified into a written rule system called Semantic Versioning. The still-valid 2.0.0 version was released in 2013.

Where things stand

At the end of 2026, this is the default numbering convention in the open-source world and major package managers (such as npm and Cargo). However, among AI tools, models, and agents, the picture is mixed: many use date-based or custom naming instead.

Status: 2026 November

Also known as

SemVer · semver · semantic versioning · semantic versioning · semantic versioning · semantic versioning · MAJOR.MINOR.PATCH · Semantic Versioning 2.0.0

Sources

This entry was machine-edited and has undergone machine expert review; the “In the news” section updates automatically from Agent Age stories.