Why you should care about semantic versioning (SemVer).

Dependency management is always hell.I was a bully once in updating my android app dependencies. Until that dark day came into the picture. Suddenly my app uninstallation events went up. Firebase crash reports waking me up now and then. I don't have billions of users. But still, I have some loyal users (I have around 2L. Not bad for some app developed for my personal use. If you are VLC user you can give it a shot - VLC Stream and remote).

The update was very simple. I just wrapped my code in the try catch block to avoid crash ( I am yet to find the perfect solution for that ;-)) and updated some dependencies. that's it. The culprit was one of the support dependency I updated before. It broke the functionality of splash screen.without it, everything is meaningless in my app. As an indie developer, I don't have much time to test our pet projects and I don't have extensive test cases in my project.

After that I have always thought, 'Why should I change something that isn't broken yet?'. I was reluctant to change to support library dependencies until I had no other go. Because it always broke something in android. Android versioning was not great until they announce this.

The same applies to node projects, ember, react, angular, etc. while choosing dependencies, check whether it follows SemVer. Otherwise, make note of it in package.json (if you are in node projects) or build.gradle (if you are in android projects).So that you can be careful while updating those dependencies. To make our life easier, there are a set of rules that makes this process easier. semantic versioning (SemVer) is something that we can follow in our app releases too.

SemVer is defined as major.minor.patch-(alpha/beta).As simple as that. Ex, (1.2.14, 1.2.14-alpha).

• A change in major version denotes it has some breaking changes. The old API is incompatible with our old code. (Ex 1.20.0 -> 2.0.0)
• A change in minor version denotes it has some new functionalities and might have some bug fixes that are compatible (hopefully) with old dependency version. (Ex 1.2.0 -> 1.3.0)
• A change in patch version denotes it has some bug fixes and there is no API or functionality changes. (Ex 1.2.2 -> 1.2.3)
• (Optional) prerelease tags (alpha/beta) - Added for our own convenience. varies dependencies to dependencies.

Sample projects which follows semantic versioning, Ember.js, React.js, More about react versioning policy.

Some important rules of SemVer. Go through this. You will understand the four points mentioned above.

• Each element MUST increase numerically (Non-Zero and positive number). For instance: 1.9.0 -> 1.10.0 -> 1.11.0
• Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version. (Once the code is tested with some version, It is always the same forever).
• prerelease tags gets lower precedence. ex, (1.0.0-alpha < 1.0.0)
• When a major version is bumped. minor and patch versions are reset back to zero. (Ex, 1.23.4 -> 2.0.0).

For more details, check here.