DEV Community

Zell Liew ๐Ÿค—
Zell Liew ๐Ÿค—

Posted on • Updated on • Originally published at zellwk.com

Semantic Versioning

We created numbers like 1.0.0 and 1.0.1 for releases and hotfixes when we worked on Git Flow. What do these numbers represent, and why do we use them?

These numbers represent the version number of the product we put out in the world. We use them because we're following a best practice called Semantic Versioning.

When we use Semantic Versioning, developers will know whether a change will break their code. The numbers give a clue to the kind of changes that have occurred.

Many popular projects use Semantic Versioning. Examples are React and Vue.

Understanding Semantic Versioning

A semantic version has three numbers. The rightmost number is a patch version.

Patch Versions

Patch versions are used for bugfixes. There are no functionality changes. (That's why we use a patch version when we released a hotfix in the previous lesson).

When you increase a new patch, you increase the rightmost number by 1. From 1, you increase it to 2, then to 3, and so on.

If your patch number is 9, when you increase the patch version again, you increase it to 10, then 11, then 12, and so on. (There are no limits to the numbers)

A patch version is the rightmost number

Minor versions

The second number is called the minor version number. It is used when you release new functionality in your project.

When you increase the minor version, you also increase it by one. But when you increase the minor version, you must reset the patch version to zero.

A minor version is the second number

Major versions

The leftmost number is a major version. When you increase the major version, you tell people that there are backward-incompatible changes. People may experience breakage if they use the next version.

When you increase the major version number, you reset both patch version and minor versions.

A major version is the leftmost number

Pre-releases

If you want to create a pre-release (like an alpha or beta version), you can add a -, followed by the words alpha or beta.

There are no hard and fast rules for pre-releases, so you can name them anything you want. Usually, we use alpha or beta, followed by a number, like alpha1.

Starting a project

Most people start projects with 0.1.0. When you're ready to release the project to the public, you increase the version to 1.0.0.


Thanks for reading. This article was originally posted on my blog. Sign up for my newsletter if you want more articles to help you become a better frontend developer.

Top comments (2)

Collapse
 
skuzzle profile image
Simon Taddiken

Please note that there actually are rules for pre-release identifiers when it comes to precedence/ordering. See semver.org/#spec-item-9 and semver.org/#spec-item-11

Collapse
 
crongm profile image
Carlos Garcia โ˜…

Thanks for the quick and easy explanation. As a developer you see these numbers everywhere, but many do not know what they mean exactly, specially those who are just starting their careers.