Back to blog

finding the perfect version naming strategy

Admin

Finding the Perfect Versioning Strategy for Your Android App

While developing the Bastion app, I struggled to manage the app's versioning (specifically the version code and version name). Because I didn't have the right tools in place, it quickly became a challenge to keep everything organized.

Android handles two types of versioning information:

1. The Version Code

The version code is an ever-incrementing integer that serves as an internal unique identifier for your app bundle. Every time you push a new bundle to a Google Play track, the version code in the manifest file must be higher than the previous one.

A common strategy that works perfectly is to use your Continuous Integration (CI) system's build number as the version code. Since CI systems naturally assign an increasing number to every build, each release pushed to the Google Play Store gets a unique, incremental version code in a way that is easy to manage.

2. The Version Name

The version name is a bit trickier. This is the string attached to the bundle that users actually see on the Google Play Store and on their phones (e.g., "1.2.0"). It is crucial to have a version name that is logical, makes sense, and is easy for the user to understand.

This gets complicated because:

  • The version name should only change once the app bundle reaches production tracks.
  • It should follow "semantic versioning" logic (for example, upgrading from 1.2.3 to 2.0.0 signals to the user that there are major changes).
  • The developer needs a consistent strategy to keep it updated.

Common Strategies

There are a couple of ways developers usually handle this:

  • Manual Updates: You manually update the version name in the source code whenever a change is needed. This is tedious and very prone to human error.
  • CI-Based Prefixing: You set the CI system to automatically name the version "1.0.[build number]" and manually update the "1.0" prefix when necessary. While this is automatic, it can lead to confusing jumps (like going from 1.0.35 to 1.1.36).

The Third Way

The best approach? Using an external tool to automatically manage these transitions for you...

— Christophe