I. Introduction
If you need to improve your Android app versioning model, you’re reading the right story. Let’s explore a few good practices and their advantages.
II. Semantic versioning
There is something in the software world called Semantic Versioning . It includes a set of conventions for assigning version numbers to your software. You can (or should probably) read its full details here . Basically the idea is as below: Regulate the increase in version number according to the MAJOR.MINOR.PATCH structure as follows:
1. MAJOR version
Increased when you make incompatible API changes (You can define rules like: when increasing minSdkVersion, Mirgrate to AndroidX, update dependencies version (Third party library version), …).
2. MINOR version
Enhanced when you add functionality in a backwards-compatible manner – Add new functionality on previous compatible configurations (Do not change minSdkVersion, update dependencies version, …).
3. PATCH version
Increased when you perform bug fixes on previous compatible configurations.
As you can see, based on the above definition, MAJOR version on an Android app doesn’t make sense unless you have any kind of API used by another client. If that’s the case, then you can use the pure Semantic Versioning definition. If not, you need to define when you should increase the MAJOR version.
An option might be to increase MAJOR when an application has a major new feature, a design change, or goal is reached. Another way is to increase the MAJOR after the MINOR version reaches 9. For example, you already have versions: 1.0.0, 1.1.0, …, 1.9.0 and then 2.0.0. It is just a regulation that determines when to increase the MAJOR.
In my case, I use two methods, but you can use whatever, as long as it is well defined and understood by all the parties involved in your application.
III. Pre-releases
Another concept defined by Semantic Versioning is the pre-release version. A pre-release version can be indicated by adding a version classifier that begins with a “-“. For example “3.1.0-beta”, “1.2.0-rc”, “4.1.3-preview”, “2.3.0-alpha”, “1.3.2-SNAPSHOT”.
You can use version classifiers to quickly indicate the version type of your application to avoid confusion between a pre-release and a release version. For example, in my case I use “-SNAPSHOT” in development phase and delete the APK release process process classifier.
If you use Google Play Alpha / Beta Testing please note that it is not a good idea to upload an APK with a version name ending with “alpha” or “beta”. The reason is that once you promote the APK for the product, you cannot change the version name, so your users will believe that they have an unstable version installed.
IV. Version code & version name
As you probably already know, for Android you have to define two version fields for an app: version code (android: versionCode) and version name (android: versionName). The Version code is an integer value that increments what the application’s source code version represents. Version name is a String value that more informally represents the version name that is displayed to the user. You can get more details from here .
It is a good strategy to get direct linkage between versions in order to avoid confusion in the process of developing and implementing releases. At least you can deduce the version name from a version code.
As detailed here, there is an official proposal to use a version code schema that links the version code to the version name, and also supports uploading multiple APKs to Google Play. Taking into account a great value, Google Play allows the version code to be 2,100,000,000.
We recommend using a technique to adapt to that model as well as supporting Semantic Versioning (Make sure you will need 2 characters for MAJOR, 2 characters for MINOR, and two others for PATCH version). .
It is recommended to use version code with 9 characters: integers representing supported configurations in higher order bits, and version name in lower order bits. The first two characters represent the lowest API level for your APK, the next characters are for screen sizes or GL texture formats (assign zero if you do not use these characters). Then there are two characters for major version, two for minor, and finally two characters for patch version.
For example, when an application has a version name of 3.1.0, the version code for the most visible API level is 4 will be 040030100 . The first two characters represent the lowest API level (in this case, 4), the next three characters are for screen size or GL texture formats (not used in this example, hence a value. zero is assigned), and the last 6 characters represent the version name of the application (3.1.0).
As you can see, you can start from 0.0.1 to 99.99.99. Therefore, you have room for 192-year versions, weekly releases and hot fixes not included.
V. Automate the versioning shceme with Gradle
If you use Gradle to build your app you can automatically version it according to the diagram by adding the code below for build.gradle.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | apply plugin: 'com.android.application' ext.versionMajor = 1 ext.versionMinor = 2 ext.versionPatch = 3 ext.versionClassifier = null ext.isSnapshot = true ext.minimumSdkVersion = 19 android { compileSdkVersion 27 buildToolsVersion "27.0.0" defaultConfig { applicationId "com.sample" targetSdkVersion 27 minSdkVersion project.ext.minimumSdkVersion versionCode generateVersionCode() // 190010203 versionName generateVersionName() // 1.2.3-SNAPSHOT } } private Integer generateVersionCode() { return ext.minimumSdkVersion * 10000000 + ext.versionMajor * 10000 + ext.versionMinor * 100 + ext.versionPatch } private String generateVersionName() { String versionName = "${ext.versionMajor}.${ext.versionMinor}.${ext.versionPatch}" if (ext.versionClassifier == null && ext.isSnapshot) { ext.versionClassifier = "SNAPSHOT" } if (ext.versionClassifier != null) { versionName += "-" + ext.versionClassifier } return versionName; } |
You only have to configure versionMajor , versionMinor , versionPatch , versionClassifier , isSnapshot , and minimumSdkVersion to automatically generate version code and version name values.
BECAUSE. Conclusion
In short, here are 4 main suggestions:
- Use semantic versioning or an adaptation to it, depending on what you want.
- Use a versioning sheme which links the version code and the version name. You should be able to link the version name from a version code.
- Use a versioning module that supports multiple APKs to upload to Google Play. You probably don’t need multiple APKs right now, but you will likely do.
- Use Gradle to automatically generate version code and version name for your application.
Try following immediate recommendations for your app to avoid possible headaches in the future.
VII. Reference
VIII. Source
IX. P / S
If there is a Source section, then this is a translation from the source that is linked to the original post in this section. These are the articles I select + search + synthesized from Google in the process of handling issues when making real + projects useful and interesting for myself. => Translated as an article to rummage through when necessary. Therefore, when reading the article, please note: