DEV Community

Cover image for An Introduction to Semantic Versioning
Niall Maher
Niall Maher

Posted on

An Introduction to Semantic Versioning

Semantic versioning is a system to help developers, project managers, and consumers have a universal way of understanding the release process. Semantic versioning is some guidelines so that we can understand what is happening in a release.

More importantly for us coders, semantic versioning will let us know if a change will break our code.

You will find most of the major projects in the wild on GitHub that use Semantic Versioning.

Major Version

There are two times to increment this version when there is a new

When we increment this version, it means that there are backwards-incompatible changes in this release. The API has changed and may contain breaking changes for users of the API.

Reset both minor and patch versions after the major number has been incremented.

If we were making a major release for 1.23.11 it would become 2.0.0.

Minor version

We increment the minor version when adding new features or functionality that do not break or change the existing API. When you increase the minor version, reset the patch version to zero.

Use this when you are making non-breaking changes that are not a bug fix.

If we were making a minor release for 1.23.11, it would become 1.24.0.

Patch version

Patch versions are used for bug fixes. This is when there are no functionality changes in the updates. There is no limit to these numbers, and we do not need to reset any other numbers.

If we were making a patch release for 1.23.11, it would become 1.23.12.

Pre-releases and build

We won't dive deeply into this syntax as there are many different ways to use it and warrant an article of its own, but I do want you to be aware of how to read pre-releases. But mainly, this is used when we wish to release software informally to some users for testing purposes. These are called pre-releases.

Pre-releases may not be stable or compatible with the previous major, minor and patch versions that they imply.

As an example, 1.23.11-beta.1, our pre-release identifier has two parts. The tag "beta" and a version "1". You might also see some build data also appended, such as the commit from which the build came from, eg. 1.23.11-beta.1+nialljoemaher-2bf235.

For a deeper dive, I have added a couple of links below to some fantastic articles that helped me understand the pre-release tagging. 

For the official Semantic Versioning guide -

A more detailed guide and awesome article -

Another one I liked while doing some research -

Happy coding! 💜

Follow me on Twitter

Subscribe on Codú Community

Top comments (4)

manjit2003 profile image
Manjit Pardeshi

So much useful Post... Appreciated ☺️

nialljoemaher profile image
Niall Maher


bhawesh96 profile image
Bhawesh Bhansali

IMO, this post has the power of simplicity!
Cheers :)

nialljoemaher profile image
Niall Maher

Haha I have too little attention to make it complex. Cheers!