Semantic versioning makes it easy and convenient to track, test, deploy, patch, and roll back features, enhancements, bugs, and fixes across a variety of environments in the software supply chain.

Semantic versioning provides an efficient and effective framework to version the software products so that the infamous dependency hell can be avoided.

What Is Semantic Versioning?

Semantic versioning uses the MAJOR.MINOR.PATCH number scheme for software products. For example:

How to Decide When to Update the Numbers

You should increment the PATCH number during the following circumstances:

• A backward compatible bug fix.

• A backward compatible maintenance release.

• A backward compatible hot-fix.

You should increment the MINOR number in these situations (note that PATCH should be reset to zero when MINOR is incremented):

• A backward compatible new framework adoption.

• A backward compatible new functionality implementation.

• A backward compatible framework enhancement.

• A backward compatible functionality enhancement.

Finally, you should increment the MAJOR number in the following events (again, note that PATH and MINOR should both be reset to zero when MAJOR is incremented):

• Any backward incompatible change.

• A situation in which the MAJOR zero (0.Y.Z) should be considered for development. The product shouldn't be considered stable and should not be deployed on production.

What About Versioning During Continuous Integration?

Prerelease numbers with semantic versioning can tackle the problem of versioning during CI (for example: X.Y.Z-${CI_BUILD_NUMBER}, 2.0.5-1992).

Once the software product is ready, the prerelease number should be removed and the product should be published and released to the external repository.

Finally, note that once the package is released and published, it must not be modified. Any modifications must absolutely be released as a new version.