Understanding the (Software)Build versions.(*.*.*)

Semantic versioning

Have you ever been in situation where, you have seen those complicated strings like (1.*.*) and wondered what does it stands for? Why do they keep on changing? What does each of them specify? So here is some little introduction that may help you understand the concept.

Lets Understand the Concept first.

The whole Idea behind having those string is to make sure whatever change we push across for our package/lib does not create any adverse effects on the packages or dependencies that depends upon our package/lib.

The Concept is called “Semantic versioning” to avoid situation called “dependency hell” where Its almost impossible to manage the third party dependencies.
In Simple terms you can say semantic version is “You adhere to the semantic (Logic) of the updates to which everyone has agreed to.”

Lets Understand The SemVer String now:

For simplicity lets break down the String as its usual meaning something like the below one.

*. *. * => Major. Minor . Patch

Major : It Specify the Major release/ Updates of the package/lib or tool. (Include Breaking Changes if you move from 1.0 to 2.0)

Minor : Specify the releases done for New features, Updates to existing features and so on (Does not include breaking changes.)

Patch : Most of the bug fixes. (Will never have any breaking changes.)

Now, does that string make sense to you?😅

Lets Understand With an Example how SemVer is updated.

Lets say we have following release cycle for one of our application :

V1.0.0 -> Release 1
V1.1.0 -> Release 2
V1.1.1 -> Release 3
V1.2.0 -> Release 4
V1.2.1 -> Release 5
V1.3.0 -> Release 6
V2.0.0 -> Release 7
V2.1.0 -> Release 8
V2.1.1 -> Release 9
....

Release 1 : We have an awesome Idea and we create quick draft of the application and release it.(Though there are alpha, beta, release candidate (rc) please ignore them for now) As this being the initial or first release we call it :

v1.0.0 (Major Update)

Release 2 : As the development moves ahead we think about implementing some addition feature so, we implement it and release the next build and it becomes :

v1.1.0 (Minor Update)

Release 3 : Now, at some point of time we find that v1.1.0 has a couple of bugs so, we quickly fix them and make the next release and it becomes :

v1.1.1 (Patches)

Release 4 : Eventually, we think about an awesome feature, we make the updates and release it with version :

v.1.2.0 (Next Minor release)

Release 5 : Its exactly same as Release 3 (Patch)

Release 6 : Its exactly same as Release 4. (Next Minor Release)

Release 7 : Now, At some point of time we decide to upgrade a major core feature of our application such as change in number of inputs required by library from lets say 2 to 3 or may be depreciating some feature that’s no longer needed.
At this point the existing applications which uses/depends on our library/application will not have the additional changes like passing newly added param or may depends on the deprecated feature and hence they will eventually break if they upgrade to this latest release. In order to indicate that, this release is with Major changes and without any backward compatibility we tag the release version as:

 v2.0.0 (Major Release)

So, Anyone using our library gets the idea that, the release have major updates and might cause Issue if they upgrade directly to this version without reviewing the changes.

Release 8 : Follows same as Release 3. (Next Minor release)

Release 9 : Follows same as Release 4. (Patches)

The Important take away from this is, This scheme makes its easy to manage and use the different versions of the application/library and ensure the dependencies works well as expected without creating any issues.

I hope this article has helped you to understand the basics of SemVer scheme and how the version number are maintained & updated.

Thanks for reading! 😊