It is widely acknowledged within the field of software engineering that semantic versioning stands as the predominant and most esteemed versioning methodology. In the course of this article, I have made an effort to provide an overview of semantic versioning, along with a discussion of the requisite guidelines to be observed when undertaking the versioning of software.

What is Semantic Versioning?

Semantic versioning is a systematic approach to versioning that assigns significant version numbers to Application Programming Interfaces (APIs). Semantic versioning is based on breaking down version labels into three main parts: MAJOR, MINOR, and PATCH.
Every part of the version label is treated as a number, and it is increased following specific rules that are determined by how changes affect compatibility with previous versions.

In the context of a version number structured as MAJOR.MINOR.PATCH, the following rules apply for incrementing each component:

• MAJOR version should increase when you introduce changes that are not compatible with previous versions, necessitating adaptations from existing users.

• MINOR version should be raised when you add new features in a way that maintains backward compatibility, meaning users can smoothly integrate these additions.

• PATCH version sees an increment when you make bug fixes that maintain backward compatibility.

Furthermore, there are provisions for supplementary labels denoting pre-release or build metadata, extending the MAJOR.MINOR.PATCH format.

SemVer (Semantic Versioning Specification)

Semantic Versioning Specification, often referred to as SemVer, is a set of rules for numbering software versions in a clear and understandable way.

Presented below are some pivotal regulations/principles.

1. A standard version number should follow the pattern X.Y.Z, where X, Y, and Z are non-negative whole numbers and should not have leading zeros. X represents the major version, Y is the minor version, and Z stands for the patch version. Each of these components must increase in a numerical fashion.
   For example: 1.9.0 should progress to 1.10.0 and then to 1.11.0 and so on.

2. When the major version is zero (0.y.z), it signifies the software is in its initial development phase. During this period, anything can change at any time. It’s essential to understand that the public interface of the software is not yet stable or fixed.

3. A pre-release version can be indicated by adding a hyphen followed by a series of words or numbers separated by dots after the patch version. These identifiers should only use basic letters, numbers, and hyphens (0–9, A-Z, a-z, -), and they cannot be empty. Numbers in these identifiers should not have leading zeros. Pre-release versions are considered less stable than the regular versions and may not meet all compatibility requirements.
   For example, you might see versions like 1.0.0-alpha or 1.0.0–0.3.7 to show they are pre-release versions.

4. After a specific version of a software package has been released, the content of that version should not be altered. Any changes or updates must be introduced as a new version of the package.

5. Precedence in versioning is about how we determine the order or ranking of different versions.

• It’s calculated by breaking down the version number into major, minor, and patch parts in that order. The order is established by comparing these parts one by one from left to right.
  For example, when comparing versions like 1.0.0, 2.0.0, and 2.1.0, we first look at the major version (1, 2, and 2), then the minor version (0, 0, and 1). Versions are always compared numerically, so 1.0.0 is less than 2.0.0, and 2.0.0 is less than 2.1.0.

• Now, if the major, minor, and patch parts are the same, we consider pre-release versions. In this case, a pre-release version has lower precedence than a regular version.
  For example, 1.0.0-alpha comes before 1.0.0.

• When comparing two pre-release versions with the same major, minor, and patch, we delve into the identifiers separated by dots. If an identifier consists only of digits, we compare them as numbers. If it contains letters or hyphens, we compare them alphabetically. Numbers have lower precedence than letters.
  If there are more identifiers in a pre-release version, it has higher precedence.
  For example, 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

References:

• https://semver.org/

• https://cpl.thalesgroup.com/software-monetization/software-versioning-basics

In summary, semantic versioning provides a systematic approach to versioning software, enabling developers and users to understand the nature of changes and compatibility at a glance.