It was introduced in 2009 by Tom Preston-Werner, co-founder of a GitHub. It was designed to provide a clear and universal way to mark software updates. There was a convention, which was almost the same as semver. But the word almost is not good enough, when you want to know what exactly the impact of changes is.

Semantic versioning is a convention, how to set versions to your code artifacts. It is called semantic, because it communicates the changes in the version, comparing to the previous version. Managing code dependency versions can become challenging if you are not aware of changes present in new version of artifact.

• Imagine you have 100 dependencies. How to know what dependencies can I update? Reading the release notes will be time consuming for the 100 dependencies.

• What if you need bug or security fix. Does new release contains only this bug fix or something else that can break an API?

• What if I need this new feature, but also I do not want to migrate?

• Is this version stable?

• How to add canary version build metadata into version?

All of these questions together with many others can be answered just looking at the version. SemVer has an answer to all these questions. The convention is very simple:

• X.Y.Z are the mandatory parts of version, where each letter i a numerical value

• X - called major version, updating it means that breaking changes are present in the API

• Y - called minor version, updating it means that new feature is added to the API

• Z - called patch version, updating it means that no API changes are done, only bug/security/performance fixes

• "+" indicates the build metadata (1.2.3+20240417)

• "-" indicates the prerelease version (1.2.3-canary.1)

Who is using SemVer?

• SemVer is enforced in the npm(Node Package Manager) repository. Your version myst syntactically comply with the SemVer rules. It is central part of managing versions in the JavaScript world. Though you cannot automate the validation of breaking changes npm repository. This is the recommendation of npm ath their page.

• RubyGems, package manager for ruby libraries is also a broadly adopted convention of managing artifact versions. The official documentation describes semver as a pattern you should name your version.

• Docker Hub, repository for Docker images does nor fully support SemVer, though the community want to adopt the semver. The "+" symbol is not supported in the Docker Hub and maintainer is not willing to add support for it. This is the GitHub issue maintainers comment, on the SemVer and "+" build metadata in the tag.

• Go is also embracing SemVer for its packages and describes how to do it.

Semantic Versioning solves multiple problems in the dependency management area. It is widely adopted, because it is easy to use and the version communicates changes being made. For some software projects this is go-to versioning strategy. Lots of tooling supports semver to manage package releases. It helps to remove version-lock problem, when you need to release a package, because your dependency changed and you do not know the impact of changes. Sem

Other versioning systems

Though this versioning system is not the only one. There is also:

• Calendar Versioning (CalVer), it includes year, month and possibly day when it was released (2024.01, 2024.02).

• Sequential versioning - version-1, version-2...

• Release Train Model - where you have planned release schedule and you are naming the release artifact version based on a release number, rather than on a feature completion or changes in the software. Version name can combine CalVer, Sequential versioning or other versioning models (24.1, 24.2).

There are more versioning systems used in the software world. You need to chose the right tool for the job. And in many cases the semver is a right tool.