Keep sanity with your versionCode

- 4 mins

Releasing Android apps is not a joke: Increase your version number, create a release build, sign the build, upload the APK, write nice release notes (in all supported languages!), roll to alpha, roll to beta, roll a 5% to Production, a 10%… until finally all your users get the update.

Thankfully we have learned to automate most of that. Your CI will take care of building and signing the release and upload it to the Play Store. But there are things you shouldn’t let your CI do: one of them is setting your versionCode. Let me show you why.

A thing you may be tempted to do is to let the versionCode to be the Jenkins build number. I remember BuddyBuild (RIP) gave that option as well, to set the versionCode based on their build number.

That’s a small mistake that can carry large consequences, since your versionCode and your versionName will be unrelated.

So for example if you have version 1.2.0 in production, with a versionCode of 42, and you decide to give to your beta users the release 1.3.0 with versionCode 43, the day you need to release a 1.2.1 you will be forced to provide a versionCode greater than 43, and you will force your beta users to “downgrade” from 1.3.0 to 1.2.1:

Dan Lew wrote recently an article where his team had a similar problem, check it out! http://blog.danlew.net/2018/03/15/how-to-screw-over-your-beta-users-without-really-trying/

The versionCode is more important than the versionName.

For keeping my sanity, I use the following formula:

First I define a Major, Minor and Build numbers in my build.gradle file:

ext {
versionMajor = 1
versionMinor = 4
buildNum = 9
}

And then I calculate the versionCode using this formula:

Major * 1.000.000 + Minor * 1.000 + Build

versionCode versionMajor * 1000000 + versionMinor * 1000 + buildNum
versionName String.valueOf(versionMajor) + "." 
+ String.valueOf(versionMinor) + "."
+ String.valueOf(buildNum)

With the example above the version codes would have been:

Then, the beta users would have stayed in version 1003000 and the production users would have been upgraded to 1002001.

When you create a new release, you only need to update the buildNum and maybe also the versionMinor or the versionMajor . And in our case, we increate the buildNum automatically with our release script.

Christopher Orr has a nice talk where he explains how to combine the Jenkins BUILD_NUMBER and a similar formula to the one presented here. Check it out!

Another trick: I use even numbers for release builds and odd numbers for development builds, so I can differentiate when QA reports an issue or a crash report comes.

I got this idea from the version numbering for the Linux kernel.

To finish here’s a rule of thumb: Never repeat a version number! If a release goes wrong (thank you ProGuard) always increase the build number when preparing a new release.

Miquel Beltran

Miquel Beltran

Software engineer and Android developer

rss facebook twitter github youtube mail spotify instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora