What is Semantic Versioning (SemVer)?

The lack of standard in software version specification does not provide any benefit to software developers and consumers; or even sometimes misleads them. It's possible to develop a software and name its version apple or 6.2 right away, to make people think it's highly worked on it. In this respect, there are no rules that are compulsory to restrict the developer.

However, a de facto standard, which means not ordained by law or rule but publicly accepted, semantic versioning provides the necessary constraints in this regard.

There are certain risks for developers and consumers when a software is passed from one version to another. One of the most important risks is that those who benefit from the software may not be able to fully adapt to the new version.

If the software developer uses semantic versioning standards, the new version will give the user a good idea of what he expects. For instance, if the version is migrating from 1.2.5 to 2.0.0, the code written in the old version may not be compatible with the new version. Users who are aware of the semantic versioning, knowing that backward compatibility is lost with the increase of the number on the left, and will do the necessary checks to adapt to the new version.

The semantic versioning standard was first proposed by Tim Preston-Werner to bring sanity to software release versions.

Benefits,

• Gives hints about the version changes.
• Tells if the versions have backward compability.
• With package management systems, the desired version range can easily be determined.

The semantic version format is three numbers separated by periods. All three numbers have different meanings.

major.minor.patch

So, when a patch release is made, the number on the right, when a new functionality which is backward compatible is added, the middle number, when a major release with no backward compatibility is made, the number on the left is incremented by one.

v0.1.0 // New project
v0.2.0 // Add new functionality
v0.2.1 // Fix bug
v0.3.0 // Add new functionality
v0.3.1 // Fix bug
v0.3.2 // Fix bug
v0.3.3 // Fix bug
v0.3.4 // Fix bug
v0.4.0 // Add new functionality
v0.4.1 // Fix bug
v0.4.2 // Fix bug
v1.0.0 // Has started to being used in production environment
v1.1.0 // Add new functionality
v1.2.0 // Add new functionality
v1.2.1 // Fix bug
v2.0.0 // Major release with no backward compatibility
...

Package management systems facilitates the distribution and acquisition of the software versions by automation. For example, it will suffice to define the package version as ^x.x.x to only include the versions with backward compatibility to your project.

Some version specification rules from npmjs.com:

• version - Matches fully matched version.
• ~version - Matches only patch releases. Same as 1.2.x
• ^version - Matches patch and minor releases. Same as 1.x.x
• >version - Matches versions greater than version.
• >=version - Matches versions greater or equal to than version.
• <=version - Matches versions less or equal than version.
• <version - Matches versions less than version
• * - Matches any version
• version1 - version2 - Greater than or equal to version1 and less than or equal to version2. Same as >=version1 <=version2

{
  "name": "projectName",
  "version": "0.1.0",
  "dependencies": {
      "bootstrap": "^4.0.0", // Same as 4.x.x
      "jquery": "~3.3.1" // Same as 3.3.x
  }
}