This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that “close” isn’t good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. By giving a name and clear definition to the above ideas, it becomes easy to communicate your intentions to the users of your software. Once these intentions are clear, flexible (but not too flexible) dependency specifications can finally be made.
A simple example will demonstrate how Semantic Versioning can make dependency hell a thing of the past. Consider a library called “Firetruck”. It requires a Semantically Versioned package named “Ladder”. At the time that Firetruck is created, Ladder is at version ‘3.1.0’. Since Firetruck uses some functionality that was first introduced in ‘3.1.0’, you can safely specify the Ladder dependency as greater than or equal to ‘3.1.0’ but less than ‘4.0.0’. Now, when Ladder version ‘3.1.1’ and ‘3.2.0’ become available, you can release them to your package management system and know that they will be compatible with existing dependent software.
As a responsible developer you will, of course, want to verify that any package upgrades function as advertised. The real world is a messy place; there’s nothing we can do about that but be vigilant. What you can do is let Semantic Versioning provide you with a sane way to release and upgrade packages without having to roll new versions of dependent packages, saving you time and hassle.
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 document describes version 3.0.0-devel.9 of Marcos Bash Functions Library.