Servage Magazine

Information about YOUR hosting company – where we give you a clear picture of what we think and do!

Semantic versioning

Wednesday, November 16th, 2016 by Servage

Semantic-VersioningSemantic versioning is a way to specify your application version numbers in a simple and standardized way. There are many versioning schemes available, but semantic versioning is definitely one of the most commonly used ones, and here’s why.

Major versions

In semantic versioning, a version number can look like this: 1.3.18. The first part of the version is the major version. A major version is a version that can introduce backward-incompatible changes to the software. Things that have worked previously, such as API clients, may no longer work with the new version because it has been changed so dramatically.

If you use third-party libraries in your own project and notice that the first number of the version has changed, you should make sure your code is compatible with the new version of the library. The pieces of the library that you use in your project are not necessarily affected, but you should still review the release notes of the library to be safe. Or better yet, run your tests against the new code base if you have any. If you use semantic versioning in your own project, you should not be releasing major versions very often.

Minor versions

A minor version can be found in the second part of a semantic version number. Minor versions should not include breaking changes and can therefore be considered safe to upgrade to. The purpose of minor versions is to introduce new features while maintaining backward compatibility.

Minor versions can generally be released as often as needed, although they should not be overused. It is recommended to couple multiple commits and features into one release and then publish them together as a new minor version.


The last part of the version string is reserved for patches. In this case, a patch is another word for a bug-fix release. They should only contain bug fixes, not new features. Hopefully the patches don’t break anything else because like minor versions, they are also supposed to be backward compatible.

Patches can and should be released as often as possible, especially if they fix security issues. Depending on their severity, patches for features can be coupled together like new features in minor versions. If the patch is for a critical security issue, it should not have to wait for other patches to be ready and should be released as soon as possible.

Initial release version

When a software is in development, it should use the major version 0. A development process is recommended to start from 0.1.0 but this is not a strict rule. When a software reaches the end of a development and testing phase, the version number should be increased to 1.0.0.

Semantic versioning, 5.0 out of 5 based on 2 ratings
Categories: Guides & Tutorials


You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet (leave a comment)

You are welcome to initiate a conversation about this blog entry.

Leave a comment

You must be logged in to post a comment.