Semantic versioning or SemVer for short is a software release standard that is designed to potentially eliminate confusion and helps to develop incremental software. In this article, we will discuss some of the concepts related to SemVer which are crucial to understanding how it works. We will also analyze sample config files using the semVer style. By the end of this article, you will have a better grasp of semantic versioning and especially, how it helps in building maintainable software. A software's semantic version is usually denoted by a separated by a period. 3-part digit For example: 1.4.22 Here, the first part gives us information about a release of the software. The second part tells us about a release, and the third is about a release. major minor patch In other words, we have a " like so: formula" Major.Minor.Patch A release is regarded as a if it contains just some little bug fixes and maybe additional code. patch It becomes a release if it contains a tangible amount of bug fixes and extra features. minor And then, it's regarded as a release when it contains changes that significantly alter the way it worked previously. These are called major breaking changes. SEMANTIC VERSIONING AND YOU Here are some use cases that provide more context to the importance of SemVer. 1. If you wanted to write a package for the npm ecosystem, you will need a way of communicating with users(or dependents) of the package about the release(s). Publishing a package: 2. On the flip side, if we were depending on a package or external API, SemVer could help us foresee potential compatibility problems or identify bottlenecks. Working with a third-party API: 3. Working with old codebases is inevitable. Whether it's a side project you are returning to or a new job. Semantic versioning can potentially help with damage control in this scenario. Updating a codebase: ON BUILDING MAINTAINABLE SOFTWARE... The semantic versioning principle can also be instrumental in writing scalable software. For this context, two terms come in handy: in the ecosystem is the ability of a software package or library to work seamlessly with code written using older versions of the same package. Backward compatibility NPM This means that you may update the package without needing to tweak your existing code. The carat sign is used to indicate that our app is backward compatible. ^ on the other hand, means that our codebase is kept open to new updates of the package without breaking the app. Forward compatibility, The tilde sign is used to denote this and it is usually a range of versions specified. Let's now break this down further using a sample file. ~ package.json ... "dependencies": { "sequelize": "^6.3.5", "eslint": "~7.32.0", "prettier": "^2.4.1" }, ... Here, we notice that uses the Caret symbol for backward compatibility, which means our code is compatible with versions up to but not including sequelize ^ 6.3.6, 6.3.7, 6.3.8 6.9.0 7.0.0 The next package uses the tilde sign for forward compatibility, which means our code is compatible with versions up to but not including changes to the version number, that is eslint ~ 7.32.1, 7.32.4, 7.32.9 any minor 7.33.0 Our next package is . is configured to be backward compatible. This means can only accept automatic updates from versions like but not the version number, that is prettier Prettier prettier 2.4.3, 2.5.1, 2.9.0 major 3.0.0 SEMVER AND EXPERIMENTAL RELEASES The , and tags are used to communicate software releases that are still in the test phases. alpha beta release candidate (rc) For example, the version history for below shows version 8 in its pre-release or test mode. babel/core 8.0.0-alpha.1 8.0.0-alpha.0 With this in place, we are able to communicate with our users the current status of the tool. Babel package users can then choose whether to opt in for the test phase or stick with the regular package. HOW TO USE SEMVER IN YOUR PROJECT "The simplest thing to do is to start your initial development release at and then increment the minor version for each subsequent release". (Source ) 0.1.0 semver.org When we finally get to a version that is ready and fit for public consumption as it were, the SemVer becomes 1.0.0 In conclusion, we have talked extensively about semantic versioning; what it's all about as well as the practicality of this approach in building maintainable software, and we have also seen some practical use cases in real-world software tools. Also published here.
