Mobile App Versioning: A Numbers Game
If you’ve ever looked at the App Store or Play Store listing for an app you use, you’ll notice at the very bottom, past the description and the reviews** and the other suggested apps, in innocuous medium sized font is … the version number.
The version can be just about any combination of numbers and letters that you can imagine, and different developers treat it very differently.
The versioning system that different developers use is as unique and specific as a fingerprint, and almost no two versioning systems are the same. So, If you already have your own versioning scheme, and it plays a useful role in the development, test and distribution of your application, go ahead and skip the rest of this article. But if you’ve never really considered what the version number is, or could be, used for, let me make a few simple suggestions that could make a big difference in how you track, test, and release your app.
Anatomy of a Version
To me, the perfect app version (if there is such a thing), consists of four main parts: Major, Minor, Patch, and Build.
This versioning system is built on specific ideas of how apps should be released and tested. So let’s take them in order, and discuss the implications of each part.
Major Version
For an application, the Major Version number is an entirely subjective thing. It isn’t tied in any concrete way to the development, testing, or release systems, so it’s really just a way to keep track of systemic changes to the application experience or infrastructure. The major version number usually gets incremented when dramatic changes take place for your application. This could be a complete visual redesign, an overhaul of the code or a change in the backend systems that drive the experience. The scope of a change that necessitates a major version bump is entirely up to you, and there’s no threshold or guideline for determining when it needs changing.
For a library, the major version usually indicates breaking changes. That is, a change that, should clients of that library choose to adopt it, could cause the client application to break, and thus require the client’s own code to change in order to update to this new version of the library. When libraries remove deprecated APIs, or otherwise add new ways to do things that replace the old ways, a major version increment is generally expected.
Minor Version
The minor version is the real star of the overall version. This is the version you change with pretty every regularly scheduled release, with the exception of “hotfix” releases (more on that later). In general, I prefer to operate a two-branch version control system, where you always have two branches that are active: a master branch, where all development work goes, and a release branch, that gets frozen at the point where you intend to release. Once you’ve frozen the release branch, you increment the minor version number on the master branch (to get it ready for the next release branch) and your release branch stays frozen at the current increment. But wait, you say, what happens if we find some critical bug in the release branch before the release? Glad you asked, but you’re jumping ahead. If you absolutely must know the answer to that question now, jump down to the “Build Number” section.
Patch Number
So, your release is out in production, a user leaves an angry review, and suddenly every executive on the floor is Slack’ing you to complain about it… now what? You need to somehow take the released version of the code, fix a single bug or problem, and then publish a new release with the fix in it. This is called a “hotfix” or “patch” release, and hopefully it doesn’t happen too often… but it does happen, so you have to be ready for it. The third number in the version is the patch number, which indicates that the overall version is the same, but also slightly different.
The patch number is essentially a safety net in case you screw something up and release it. If a critical bug is discovered in a released version, you can patch the bug, increment the patch version, and release that new “patched” version. Then, when the next major or minor version is released, the patch version is brought back down to zero. Obviously, the patch number should almost always be zero, and if you start seeing high numbers in the patch field, it’s a good indicator that something is wrong in some part of your development pipeline.
Build Number
The build number is the laborer, the guy you count on day in and day out to do the hard job of identifying every single build you make. In a healthy CI environment, you might make a build of your app every day. In a bonkers, obsessive CI environment with unlimited resources you might make a build of every commit. The reasons for this are varied, but maybe the most important one has to do with In-Sprint QA. Every day developers are making changes and fixing bugs, and all that code needs to be tested. If you drop all that code into QA all at once, it’s going to be more painful to diagnose problems, and it also throws a wrench into any agile process or planning you’re trying to do. Instead, we like to drop a build into QA every day, so that the Test Engineers get a trickle of changes, instead of a firehouse. But, the Testers need a way to identify which builds have which changes in them… enter, the Build Number. The build number is independent of all the other parts of the version number, and uniquely identifies the build so that QA engineers know which builds have, say, a particular bug fixed, and which don’t. When developers fix a bug or complete a story, they can add the build number that the fix or story will be in, so that QA engineers know when to expect it. This eliminates the confusion of developers fixing and merging a bug, moving the ticket for it into QA, and QA Engineers testing it in a build that was made yesterday.
Also, if you’ve already cut a release branch, and QA finds a release-blocking bug, you can just fix the bug on the release branch (don’t forge to cherry-pick back to master), increment the build number and make a brand new release version, without changing any of the major, minor or patch numbers.
In addition, the build number can also track exactly which commit the release was cut and published at, as long as you keep the incrementation of the build number in its own dedicated commit.
The version number of your app can be as simple as 1,2, 3, or it can be as mysterious and inscrutable as whatever Netflix is doing, but no matter how you choose to version your app, it’s important to realize the the version number has real implications and benefits for keeping your development house in order. Instead of just bumping the number from time to time whenever you need to publish, put some thought into what your version number can do for you, and change it often.
** or just above the reviews on the App Store