By James Baud
A critical part of software development is tracking the life cycle of a given set of code. To that end most code contains a version name or number to help with life cycle management. I have outlined four popular options and an approach that I came up with at work.
Marketing Names: These are code releases named primarily for marketing reasons. Microsoft’s operating system is a great example of this – where version numbers jump around between names and numbers and years of release. Normally these names span a collection of code builds and there is a secondary version number. These style names are easy to recall and talk about, however the order may not be clear; doubly so when trying to give every code build a name.
GitHub Hash: This gives an easy way to track a given code release back to a commit, however it is more or less unmanageable as a function of being able to say or to know what order the releases were processed.
Date of release: These are names that are based on the date of release. Ubuntu uses this format as do the underlying Microsoft Office build numbers. This system can fall apart when releases come out often and one is trying to give every build a unique name. The other issue is that when releases run behind, the November release can be deployed in February.
Semantic Versioning: A very popular standard is Semantic Versioning. The current release of the standard is 2.0.0. At a high level, the format is “MAJOR.MINOR.PATCH” and numbers increment as needed based on how impactful change is on the level of an API. Using Semantic Versioning makes it clear the level of the change and the order that the releases come in; however, as the version is all numbers it is boring and hard for people to recall.
My team interacts with a lot of non-technical marketing and business users who like to know what code releases are going to contain their functionality or fix. We tag each release with a Semantic Version number and a GitHub hash, however the business users didn’t like either of those approaches. To help with that, we started to use friendly release names based on when they should go out. But with the goal of releasing every two weeks, the date-based release name quickly didn’t line up with the day the code was released; this causes secondary issues of making it clear how far behind some of the releases had become.
I came up with an idea to create a list of friendly product names akin to how each year has alphabetized hurricane names. i.e.) Apples, Banana, Carrot, etc. This strategy solves a collection of problems – it creates release names at the scale we need, making the order of releases clear, and eliminates naming impacts if a release comes out later than planned. The best part of this solution is that the names have meaning to the non-technical sponsors of our projects. When talking with these users, we refer to a release by its friendly product name and how many times we have built a release candidate on that name. We then step to the next name in the list when code is deployed to production. Once we complete an A to Z cycle, we start back over at the next A name. I created a list of about a thousand product names already sorted in the correct order.
Since implementing this approach, we have noticed an improvement in the interaction with our business community using the new naming convention. They clearly understand the expectations of a release based upon the friendly name and our ability to align their functional needs with the actual technical deliverables has shown significant improvement as well.
