By: Saurav

2019-08-09 19:32:00 UTC


On your journey as a developer, you would have been assigned the task of creating a package and putting it out there. Maybe it is an NPM package or a Ruby Gem. Even if you haven't done something of that sort, you might want to extract out things that might be common among multiple projects.

Say you have a few CSS files you want to use across multiple projects and want to follow DRY (Don't repeat yourself) pattern. Or maybe you are a react developer and have a few basic components like buttons or navbar or pills which you want to reuse across other projects. In all these cases, you can extract out these functionalities in a separate library. This blog is not about explaining that process. It is a long one and I would break it down into parts and publish more about it.

This blog post is about SemVer which will help you out when you actually decide to get your hands dirty. The industry follows what is called Semantic Versioning for versioning their software or libraries. You can read about it in-depth in the last link or a google search since there are a lot of resources available.

I will just try to give you a short concise understanding which will help you get started.

If you have used any external library before, you must have seen these. The three numbers separated by dots.

As the pic above illustrates, the leftmost number is for identifying Major Version, the middle one is to identify the minor version and the rightmost is for patches. So what the hell these mean? These are standardized jargon used and agreed upon by developers across the world.


- Let's start with the rightmost:
- When you fix a bug in your code and do not add any new functionality to it, you increase this one by one.
- Normally you start a project with 0 for the patches and as you go along and fix a bug, you increase the patch by one. If you are in react, this number exists in your package.json file under the key version.
- It can go from 0 to any number. (But if you are doing so many fixes, you are doing something horribly


- This one sits in the middle
- When you add new functionality or a new feature that doesn't break anything, you increment this one by 1.
- When you increase this by 1, you reset the Patch to 0
- IMO, this would be the most used update in your version number since you would be adding more and more features as you go along


- This one sits on the left
- It's kind of an alarm for your library's users saying:

Brace yourself tax season is here

- It signifies a major change. Things might break and the users should be ready for a few/lots of things breaking
- This would be the least used one while updating but signifies considerable changes in your code.
- When you increment this one, you have to reset all others to 0. So minor and patch becomes 0.

Bonus: Pre Release

- You might have seen something like this with trailing alpha/beta

Screen shot 2019 08 09 at 12.59.48 pm

- This alpha/beta is used to identify a pre-release. In otherwords, it says the library is still being tested and bugs will happen
- You can add any words you want. Just add a "-" and then add the word after the three version number.
- But do keep in mind everyone knows what alpha/beta means since its standardized.
- Your library users probably won't know what "1.0.0-allhailtheking" mean. So if you want other users to use your library and take pride in the contribution to the open-source, try sticking with the alpha/beta jargon for pre-releases.

Hope this helps! :)

Let me know what you think!
twitter: sprakash24oct

Owned & Maintained by Saurav Prakash

If you like what you see, you can help me cover server costs or buy me a cup of coffee though donation :)