Software Versioning

Scott Adams in his iconic Dilbert comic says that software is never finished. What the comic argues is that software development by definition is bound to incorporate changes and will involve changes to accommodate either business needs as improvements or bug fixes which were initially unidentified.

This inherently makes an argument that software is built in multiple releases. Each release is defined to solve specific problems – either add new features, fix old bugs.( and perhaps add new ones)

If you are writing any kind of software in today’s world, it’s imperative that you version your software.

Versioning Software

Software versioning has been a long standing practice which I’m sure emerged as a need. Necessity is the mother of invention. Linus Torvalds while writing code for the linux kernel realised the need to build a software versioning tool. This led to the development of today’s most used tool – git – for software versioning in 2005. A Linux Journal article details on origins of git as a software versioning tool.

Modern software development involves git as a de-facto source code versioning tool. It’s not that git is the only option available to version source code but is certainly the most widely accepted one.

 Mercurial(Hg) being another one.

It’s not necessary than one is better than the other in all aspects. Steve Losh’ in his article details on the real difference between Mercurial and Git.

Companies like Github, Atlassian and Gitlab have based their entire product lines on the concept of software versioning. It’s certainly not a trivial problem to solve and therefore you do see Github, Gitlab and Atlassian like giants existing in the market and vying for market share but largely dominated by Github as per  this report.

Versioning Conventions

Versioning software involves versioning source code to distinguish feature sets. Agile development methodology states that software releases incorporates group of feature sets released together and named as one release. There are several releases after the first release. These are generally termed as release milestones and companies have their traditional way of calling it out. Most companies have a release plan and abide by it for every product release.

Microsoft has a long standing tradition of naming it’s early product releases as Preview.While Google and other companies alike call it Alpha, Beta releases.

If you’re interested in release planning, I like how Mozilla details on release engineering in their wiki. It’s a release plan which is followed for all of their open source contributions.

These releases distinctions are largely around the target audience it’s intended for. For instance, most Preview or Beta releases by companies are intended for the early adopters. Early adopters, review and crtically analyse the software. They are generally okay with bugs or non-functioning of certain features and are willing to experiment your product. Most companies deliberatly ship Preview/Beta release to test market acceptance and get early feedback. It’s a good way to test out whether your release was okay with the known bugs or limitations or not. .

Semantic Versioning

A deeper sense of versioning software is related to semantic versioning. This is largely the versioning conventions which is targeted for software developers and perhaps other softwares which depend on the software being released. The audience which reads these releases are developers who are using their product. Semantic versioning involves following three key components to it’s schema


(Soft,Hard)Ware versioning for Internet of Things

Having worked in the IoT domain for the last 5 years, I’ve accumuated some sense of versioning software which works in tandem with hardware versioning. A hardware version can refer to the kind of chipset it’s built with. This chipset and other components associated with the hardware may determine the kind of software(or firmware) that can run on the hardware. This leads to another level of complexity which entails software versioning with respect to the hardware versioning.

A hardware version, semantically labelled as 1.1 may only work with software version 0.1 and therefore the developer cannot upgrade software(typically called firmware in the industry) beyond 0.1.

This is IMO an extension of semantic versioning of software and nature of it’s dependencies. A software or firmware versioning is inter-linked with the hardware version as well. This is not a big problem when dealing with virtualised hardware – largely true for the software running on cloud but becomes an increasingly important problem for the software or firmware running as close to the hardware. Essentially, closer you get to the hardware, more one needs to worry about the software and hardware versioning dependencies.