In the world of software management there exists a dread place called “dependency hell.” The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.
What is this?
If you aren’t already using Semantic Versioning, you should. It makes it much easier to figure out how to version your releases. Even if you’re ‘just’ building software for your internal organization, or a single customer, you should still care about versioning of the software you release. Instead of an ad-hoc versioning scheme, Semantic Versioning offers a set of easy-to-understand rules about when to increment which version number.
- increment the patch version (e.g. from 2.3.4 to 2.3.5) when you only release bug fixes
- increment the minor version (e.g. from 1.3.2 to 1.4.0) when you add new features
- increment the major version (e.g. from 3.2.9 to 4.0.0) when you introduce breaking changes
Why should I care?
This makes it much easier for you when you need to make a decision on a new version number, and it also makes it much easier for consumers of your software to understand when an update is ‘safe’, and when they should set aside some time to test compatibility.
If all of this sounds desirable, all you need to do to start using Semantic Versioning is to declare that you are doing so and then follow the rules. Link to this website from your README so others know the rules and can benefit from them.
This is somewhat of a rip-off of Mark Seemann’s post on Semantic Versioning with Continuous Deployment, which somewhat of a lesser rip-off of the original page on Semantic Versioning, created by Tom Preston-Werner, co-founder of Github and also the guy who made Gravatars.
OK, I want in.
All of that being said, check out the official page at semver.org for detailed specifications, examples and a very useful F.A.Q. section. I think this is a great starting point for when we dive into How to: Use tagging in Git (Part VII).