Semantic versioning

Content and code versioning Semantic versioning Upstream Subversion notes Git notes

Semantic versioning (a.k.a. semver) says that when you see versions like:

3.1.0

to read them like:

major.minor.patch

where

• you increase major version to signal breaking changes, such as API changes

• you increase minor version to indicate added features, but existing parts act the same/compatibly

• you increase patch version to indicate bugfixes and other patches

Exactly what consists of breaking changes is still up to some interpretation and may even vary with language.

Say, renaming a keyword argument isn't even a functional change, but in many cases is a breaking API change in that calls by keyword will now fail.

People may not update major release until it's a large feature change that also happens to be breaking, minor for "we're working on serous things".

---

You can also add prerelease label and/or metadata, like

major.minor.patch-prerelease+metadata

For example

1.2.1-beta3+20190214

Semver sorting

See https://semver.org/#spec-item-11

• major, minor, and patch must be split, and sorted as integers

meaning that lexograpical sorting is incorrect

• things with a label come before those without
• labels are sorted lexograpically

• metadata is irrelevant to sorting