Versioning

For too long I didn't really think about versioning of code. More than just the use of SVN or Git, but of versioning code that is to be used in a production (i.e. 1.0, 1.5, 2.0, etc.). Versions of code were just numbers and didn't really matter much to me. Typing that last sentence just made me cringe a little. Something like this isn't uncommon for developers or many other professions. If you think back on different practices or malpractices that you used to employ. Looking back at code that you wrote a long time ago or even maybe a couple months ago wondering who could have possibly written this blather only to see your name all over the commit logs. As a method of correction we look outside of ourselves to find ways to better our craft.

One such inspiration I came upon was http://semver.org/. While I can't say how I was first drawn to it, I do believe it was some projects on http://github.com . The first time I encountered it I'm sure I clicked on the link out of pure curiosity, glossing over it. However later I finally took the time to really look over it and read everything in it. The contents themselves are not really revolutionary, but they are practical and useful when talking to others about how to version. It talks about a pragmatic way to version your code and still allowing latitudes for different company or organizational schemes. While I know that it has been used officially and unofficially, even before the Semantic Versioning concept was named it provides a useful tool for communicating what is meant by a particular version.

The only frustrating part comes when there are cases when you can't use it such as in the case I mentioned in this blog post. Semantic Versioning helps all involved assigning specific meanings to the numbers between each decimal point. It also, provides a common language to talk about versions and enforces best practices. Barring system limitations, I would highly suggest at least taking a look into it.