Why and How to use Semantic Versioning (sem-ver for short) ?

A lot of developers often fail to write a proper semantic versioning these days. Sem-Ver is one important thing that I have learnt over my 1.5 years of experience.

Many libraries,modules are being developed to maintain a universal versioning system everyday, in order to keep track of HOW the software development is being carried out.What do you understand by a version say for example 1.3.8 ? Any idea ? Lets break this into 3 simple chunks say x.y.z , Now :

  • x in the version above stands for Major Release Version.
  • y in the version tells about the Minor Release Version.
  • z, on the other hand tells about the Patch No.

So, 1.3.8 can be understood as 8th Patch in 3rd Minor Release of 1st Major Release.Now lets talk about Patch, Minor Release and Major Release :

  • If we fix a bug or any minor issue, in the current product we just push “z”.This is called Patch. A very simple example can be say, On 1.3.7 you have a few console.log statements which you used for debugging purposes and forgot to remove them. In this case you can push the new build with version as 1.3.8.(This example is very basic, in real world you work on fixing many major patches).
  • If you are implementing any new feature in a backward-compatible way, then you will increase the “y” in x.y.z, because this is known as a Minor Version. Minor Release is a release that adds feature to the API but does not change the existing API, you may have added a new feature that does not make current clients incomparable with the new version.For example consider a simple API, on calling which you send the user details, now one day you decide along with sending the user details you will also send “location details” say Address for some or the other purpose then this change can be categorized as a Minor Release. We generally set the Patch to zero (z=0) while pushing a Minor Release.

Major Release is something in which you break the existing Public API, say you introduce new features in backward-incompatible way. Say changing your authentication mechanism from basic to advance (OAuth) which then allows users to sign up with several social networks. In this case you update the “x” in x.y.z.

We start at 0.1.0. Do a lot of make and break before 1.0.0.We even push builds like 1.0.0-alpha. 1.0.0 is the stable deployment which has clients relying on it.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.