Semantic versioning

In the world of software development, we often rely on other sets of program files called packages. Packages facilitate development time with code reusability. Another important feature is that they can be shared globally as external libraries for other developers, so they don't have to write everything from scratch. As the complexity grows, so does the number of packages we have to integrate. Packages get updated for various reasons; updating them might break our existing codebase. But we might miss out on important features or patches if we don't update them.

Luckily, we don't have to guess if an update breaks our code or not because semantic versioning is here to solve that problem. It is a way of versioning software releases so that we know exactly what kind of update it is.

Semantic versioning structure

The basic structure of semantic versioning, also known as semver, goes like this: Major.Minor.Patch.

For instance, let's have a look at a package called pie.

From the version number alone, we can get the following information.

• The major version release is 3. This shows that the major version was released 3 times. And each major version had at least 1 incompatible change.

• The minor version release is 1. It shows that one backward-compatible feature updates with the current major version.

• The Patch version is 4, which means it underwent four bug fixes that are backward-compatible with the current minor version.

Major version

The first digit of the version number must be a positive integer number unless it is the pre-release or unstable version. In this case, it starts from 0.

1.0.0       // a new release
0.1.0-alpha // pre release

When an update introduces backward-incompatible changes that break the compatibility of the code, the major version is incremented, and minor and patch versions are reset to 0.

If our pie package goes through a major update, its version will be:

3.1.4 // before
4.0.0 // after the major update

Minor version

The second digit of the version number starts from zero if the major version is greater than zero. If the major version is zero, then the minor version starts from one.

1.0.0
0.1.0

The minor version is incremented when backward-compatible feature updates are introduced. In this case, the package functions the same way as before but with additional features. Incrementing the minor version will reset the patch version to 0.

If our pie package gets a feature update.

3.1.4 // before
3.2.0 // after the feature update

Patch version

The third digit of the version number starts from zero. It gets incremented for every patch introduced to the package. Patches are a way to address security vulnerabilities and bug fixes.

A patch for our pie package.

3.1.4 // before
3.1.5 // after the patch

Conclusion

To sum up, in this topic, we've learned how to version packages according to semantic versioning specifications:

• Major version: incremented when backward-incompatible changes are introduced to the package.

• Minor version: incremented when backward-compatible feature updates are made.

• Patch versions: incremented when backward-compatible bug fixes occur.

We can update without breaking compatibility with the help of semantic versioning.

Now, let's practice semantic versioning!