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.

The missing component in my software development

I recently came across a job description for Software Engineer position at a startup which read –

Join us as a Software Engineer if you believe in this –

You don’t take pride in the code you write but the software that you deliver.

That’s when it just struck me.

That’s what the missing piece is. DELIVERY.

I figured that it is one of the reasons I miss on deadlines I set for myself. (I missed one yesterday which I’d set a week ago for a feature release. It’s disappointing and I am determined to work upon it.)

I realised that all I was doing was just thinking about the “CODE” and estimating the timelines. I was missing out on the “DELIVERY” component.

Whenever I am working on a feature release, I try to start with a Design Document and an Information Flow Diagram. That’s an awesome practice that I try to follow. It helps me plan my code’s structure really well and helps me visualize how different components of my stack would interact. What I miss out is the “DELIVERY” part.

My Thoughts on Missing Software Delivery Component

  • Being a finisher – Software Delivery requires a key ‘feature’ which most of the software developers lack – ‘Being a finisher!’. I think most of us face this problem and it’s hard to overcome. John Sonmez from Simple Programmer talks in-depth about it in this blog post. Highly recommended read.
  • Feedback inclusion time – Post software delivery, try to reserve sometime to iterate over the feature released based on the initial feedback from early users of software. Try to keep this feedback loop as small as possible. Eric Ries in his book Lean Startup talks in depth about this feedback loop. More concrete thoughts with context to my work were a result of my recent discussion with Amarjeet, CTO and Co-Founder at Zenatix.

If you’re like me and struggling with estimating software timelines, I highly recommend this book – Software Estimation by Steve McConnell

If you’re not a reader type of person, listen to this podcast by Steve on “Estimating Software“ at Software Engineering Radio

If you’ve got thoughts on software delivery, do comment on this blog post to discuss and provide feedback.

Terminal Setup to Boost Productivity

Terminals are software developer’s best friend to boost productivity. Even in today’s age of super complex IDEs, having a highly productive terminal setup can vastly increase the pace at which you get your tasks done.

Here, I will cover my terminal setup which has vastly enhanced my productivity.


I recently ditched the default by OSX and replaced it with iTerm2 and I am definitely not going back.


Z Shell or Zsh is another shell implementation similar to Bourne Again Shell(BAsh) and also a scripting language. All features of BAsh are already integrated in Zsh.


sudo apt-get install zsh

If you face issue installing on Ubuntu, follow this thread.


brew install zsh

If you wish to understand why Zsh is awesome, check this desk by Brendon – Why Zsh is Cooler than Your Shell

Some useful links:

Adding plugins to Zsh

OhMyZsh – Get Oh My Zsh using the following command.

sh -c "$(curl -fsSL"


It is a program which runs in your terminal and let’s you switch between several programs and do a lot more. More details about tmux are here.

Customising tmux

tmux uses a file called tmux.conf to store it’s configuration.

Here’s my tmux.conf.

set-option -g default-shell /bin/zsh

# Tmux uses a 'control key', let's set it to 'Ctrl-a'
# Reason: 'Ctrl-a' is easier to reach than 'Ctrl-b'

unbind C-b
set-option -g prefix C-a
bind-key C-a send-prefix

This is most basic customisation. You can do much more than this Read more here.