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.

GopherCon India 2017 Experience

3:30 am flight to Pune – just to optimise on the cost and time!

Awesome. Totally worth it.

The GopherCon India 2017 was extremely well organised by Emerging Technology Trust with an excellent Master of Ceremony- Gautam Rege. The conference began with a keynote talk by Frances on “context” package and was followed by several interesting talks on a variety of topics. Overall there existed a good mix of architecture as well as implementation level talks. It was the third edition of GopherCon India attended by close to 300 delegates with representation from 12 countries.

Key Talks

Following are some of the talks which I particularly liked.

  • Fast and Scalable Machine Learning with GoLang by Vidyasagar Nallapati – Talk slides
    • Vidyasagar talked about how they built data pipelines using services written in Golang at EMC2, their reasons for exploring Golang as a programming language.
  • Building Distributed Timeseries Database in Go by Matthew Campbell – Talk Slides
  • “Flogo – A Golang-powered Open Source IoT Integration Framework by Kai Wähner – Talk slides

My Lightning Talk – Server Monitoring using Influxdata

I got an opportunity to give a lightning talk on ‘Server Monitoring using Influxdata’. I detailed about how at Zenatix, we’re using Influxdata’s TICK stack for monitoring our servers with right alerts in place. I followed it up with demonstrating some Golang code for writing a Telegraf plugins. Talk slides

Lighting Talk Slides

Key Projects Takeaway

My discussions around projects revolved around IoT and Data Analytics. Following are some of the good projects that I’d like to try out in-depth.

  • Flogo – Open source project written in Go for IoT integration. It’s a project released under BSD-style license. It’s definitely one of the projects that I would like to explore from the architecture standpoint.
  • Gobots – I came to know about this through on my hallway discussions.
  • Vulcan – Matthew is his talk detailed on how they built Vulcan on top of Prometheus at DigitalOcean. This issue on GitHub details on why Vulcan exists.

The Hallway Tracks

These are tracks which happen when you’re interacting with attendees in the hallways. One of the core reasons why attend most conferences!

In these ‘tracks’, I discuss about the problem we’re solving at Zenatix and also get a perspective on what others think about it.

I had an amazing discussion with William Kennedy on writing a proposal document before planning any feature/bug. According to him, one should try to bring in “Why” before writing any line of code.

According to him, while writing a proposal document, outline it in the following manner.

  1. History of the problem – Give users a flavor of the problem with information around the problem. This is more like the literature survey in academic publications.
  2. Problem definition and why you’re solving it. – Mention the core of the problem and reasons for solving it.
  3. How we’re solving – Details on how we’re going to solve it.

I highly recommend everyone to read his blog.

Overall Experience

I had a tremendous learning experience at GopherCon India. The GoLang community in India is pretty young. There is a lot that needs to be done to spread the magic of Go around. I believe conferences such as these are one of key factors in determining the success of the community. Kudos to everyone involved with GopherCon India 2017.