Good build numbers

In my opinion, a good build number shows the current state of the software version. It’s not a timestamp or a random increasing number, so it shouldn’t change when I build a version twice! A bigger number indicates a more advanced version of the software because we all know; A higher number is always better, everybody understands that.

Microsoft does a pretty good job with their build numbers for Windows. It’s clear that 11082 is a lot older than version 14342, and there’s no big difference to the latest version 14352.

SVN also use good versioning by increasing the revision for every commit — it’s the same revision for both local and remote builds. However is not possible in git because branching is so common (and that’s a good thing). Counting the commits of the current branch isn’t accurate. “342. commit” doesn’t point to a specific commit and multiple commits on different branches could have 341 ancestors.

Static build numbers for git

I thought a lot about this problem and came up with the following solution:

For every build I count the commits into the main branch (“master” or “develop” for most people). This commit number is a good start but not enough as I think it gives too many insights into the project. Once a client knows that the commit count is equal to the build number they start asking why the commit count is so high/low for the latest release. That’s why I add the project age (initial commit to latest commit) as the seconds part to the revision and add them together.

I decided to give one year the value 1000 — this means that the revision count increases every 8.67 hours. When you started your project half a year ago and you have 325 commits the revision is probably 825. This number is easy to understand, stable for every commit (locally and on Jenkins) and always increasing.

Multiple branches

The number alone doesn’t solve the multi branch problem. To solve this I add a second part to the build number, the commit count on the feature branch since last merging the default branch and a two character identifier (hash) of the branch name (example: 825-ud4). When you see another build with the same build number (825-za2) it’s easy to recognize that both builds are build on top of the same commit (build number 825). Apparently those builds are from different branches because of different branch identifiers.

When you told a client that feature X is available from build 450 on he will never ask why the feature isn’t in build 436-as16. And while developing feature Y you can provide “wt”-test-builds and your client knows that feature Y is available in build 421-wt6 as well as 532-wt6 (where you merged the latest 532 build from the default branch into your feature branch of feature Y).

Local Changes

Sending debug builds to the client is not a common practice. But it happens that a debug app version stays on a device of the client because a bug on that specific device required debugging on it. I also share the same test devices with QA. Identifying debug builds with local changes is very important.

I add the number of local changes and a big -SNAPSHOT to such a build.

1083-dm4(6)-SNAPSHOT

This build has 6 local changes on a feature branch (dm) with 4 commits