It is just Numbers and Dots, right?

I just released a new version of software. I called it 1.0.0. Why did I do that? Really it was because that is just what I do. When I make a very tiny change I adjust the last number up. When I have enough tiny changes that I can bundle them up I adjust the middle number and when I have a significant number of those changes I adjust the first number.

Is this right? No, no it is not. So it’s time to figure this out. Let me go to the source:

(from http://semver.org/)

Summary

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

This makes way more sense. When you make incompatible API changes the major version must change, otherwise it is just extending the current versions functionality (still backwards-compatible) and finally if you are making changes, that don’t add functionality but fix originally intended functionality while maintaining the same backwards-compatibility it is a patch.

Why should I care? Do you want to live in dependency hell? I thought not. The more complicated software gets, the more likely conflicts occur among dependencies and interdependencies.  How do we avoid this? By making sure that when we write a library with a public API we show how it’s used and how it will not be used. Once these restrictions change we know we have to think about bumping up the major version. Those who want to keep their code working can stick with the working major version until they have reviewed potential impact and decide to upgrade or not.

It is not overly complicated, but I highly suggest reading the full spec to become fully enlightened.