Semantic versioning

Semantic versioning is a versioning scheme that conveys meaning about the underlying code and what has been modified from one version to the next. It helps developers understand the impact of upgrading to a new version of a library or application.

Semantic versioning is based on the following principles:

1. Version number format. Semantic versioning uses a three-part version number in the format MAJOR.MINOR.PATCH. For example, 2.1.7 specifies major version #2, minor version #1, and patch #7.

2. Backward compatibility. A new MINOR or PATCH version should be backward compatible with the previous version. This means that code written for an older version should work with the new version without modification.

3. Incrementing the version number. When making changes to a library or application, the version number should be incremented based on the type of change:

• Major version: Incremented when making incompatible API changes.
• Minor version: Incremented when adding functionality in a backward-compatible manner.
• Patch version: Incremented when making backward-compatible bug fixes.

Say you have a library with version 1.2.3. If you make a change that adds new functionality in a backward-compatible manner, you would increment the version to 1.3.0. If you make a change that fixes a bug in a backward-compatible manner, you would increment the version to 1.2.4. If you make a change that introduces an incompatible API change that requires existing users of your library to change something in their code, you would increment the version to 2.0.0.

The concept of semantic versioning is integrated into modern package managers, such as npm, pip, composer, and others. When you add a 3rd party library to your project, you can specify a version range to ensure that you get the latest bug fixes and features without breaking your code due to incompatible changes. For example, if you specify a version range of ^1.2.3, you will get any version that is 1.x.x and has a patch version of at least 3. This allows you to automatically get the latest patch and minor versions without breaking changes.

Other kinds of version numbers and labels

In addition to numerical versions, you can also encounter other types of versions, numbers, and labels in the software world:

• Build number: A build is the process of transforming source code into an executable program or library. Compiling the code, running tests, and packaging the result into a distributable format are all part of the build process. The more complex the software, the more steps that are involved in the build process. For something like an operating system, the build process can take hours or even days. The build infrastructure itself can be quite complex and can cause bugs in the final product, so it's important to have a history of builds and to be able to reproduce them. That's why in complex software projects, each build is assigned a unique build number. Build numbers are usually sequential and can be used to identify a specific build of the software. For example, 1.0.0..uild123 refers to the 123rd build of version 1.0.0. Build numbers are often used internally by development teams and are not exposed to end users; however, you can still see them in some programs.

• Nightly: Versions that are built automatically every night from the latest code in the repository (e.g. 1.0.0-nightly.20220315). Nightly versions are usually accompanied by a date or a build number. These versions are typically used by developers to test the latest features and bug fixes and to report any issues to the development team.

• Alpha: Versions that are still in active development and not yet stable (e.g. 1.0.0-alpha.35). They are usually released to get early feedback from users. Any nightly build can be promoted to an alpha version if it's considered stable enough for testing.

• Beta: Versions that are more or less finished and stable but still not considered production-ready (e.g. 1.0.0-beta.1). These versions are usually released to a selected group of users (called beta testers), usually volunteers or employees, to test the software in real-world conditions and iron out any remaining bugs.

• Release Candidate (RC): Versions that are considered stable and ready for production but still need to be tested by a wider audience (e.g. 1.0.0-rc.1). These versions are usually released to the public to get feedback from a larger group of users. If no major issues are found, the RC version is promoted to the final release.

• Stable: Versions that are considered stable and production-ready (e.g. 1.0.0). These versions are released to the public and are recommended for general use.

• LTS (Long-Term Support): Versions that are supported for an extended period of time (e.g. 1.0.0-lts). These versions are usually maintained for several years and receive security updates and bug fixes. Of course, not all software has or needs LTS versions. It's more common for large pieces of software, such as libraries, frameworks, or operating systems that are widely used in production environments. People who use this software in production environments need to be sure that they can rely on the software for a long time and that it will receive security updates and bug fixes.