Each piece of software that’s released has a purpose and whether you’re writing a mobile application, a web server or a language specific library to joke with your coworkers, for that purpose to be met the piece of software has to be properly distributed. A big deal of software distribution relies on doing software versioning the right way.
There are a bunch of versioning policies out there that explain how versioning should be done, but you don’t really need to care about all of them. You should only need to really understand the versioning policy you are following. In the Ruby world we use the awesome RubyGems to distribute open source libraries, which has a set of versioning policies.
The most important things for a versioning policy to have is a clear a way to know the order in which the versions were released and to use the version as a guide to know when a new version is not backwards compatible.
I recently found about Semantic Versioning which seems to be a formal specification of the RubyGems versioning policy, in fact although RubyGems doesn’t enforce a specific way of versioning, they recommend using it. In my opinion Semantic Versioning rocks, specially because it simply makes version constraint work.
This is a summary of the specification:
Understanding how this works is important and it can save you a lot of headaches, specially if you are building production applications that rely on third party libraries.
If you are maintaining a gem please try to follow Semantic Versioning specification and make your gem users life easier, most gems already do. After reading the specification I decided to change Giphy gem version to match the specification.
We should all do it for a greater good.