Versioning your Software releases — SemVer 2.0.0

Semantic Versioning or SemVer has been gaining popularity over the last few years, especially with Open source software where the creators can communicate the extent of change in a release.

A simple summary of SemVer from its website describes it all.

SemVer — Semantic Versioning

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,

MINOR version when you add functionality in a backwards-compatible manner, and

PATCH version when you make backwards-compatible bug fixes.

In addition, there are optional tags which add to the schema

MAJOR.MINOR.PATCH-{pre-release}.{build}+{metadata}

Here, pre-release is generally used to describe alpha or beta releases of the Software

build — is used to describe/identify the build version (generally indicated as whole numbers)

metadata — is used to add metadata information like target operating platform ex. windows_x64

Combining them all, we get a release version as below

2.7.2-alpha.1+windows_x64

Other rules apply to SemVer as well

• The initial release version should be 0.1.0 — as there is no initial build, so 1.0.0 is incorrect, and there are no defects/patches, so 0.0.1 is incorrect.
• Once a version packaged is released, it cannot be changed. All changes need to be appended to the package, and a new version should be generated.
• A pre-release version is used to generally indicate that the version is not adequately tested and may be unstable
• Deprecating functionalities (reducing features) should be handled using minor code increment.
• If you follow SemVer, do not prefix your release version with v like v1.2.3
• Releases follow precedence and must be calculated based on the order of MAJOR > MINOR > PATCH. Do not consider {build-metadata} precedence calculation.

Thanks for reading. Follow for more helpful content