3

The answer in the question Android play console: internal testing version, close testing ? how does it works? says:

End users (or testers) cannot choose which version they want, they will always receive the APK/AAB with the highest versionCode that they are eligible for.

But I wonder: How can we continue using the internal test track for developing new features when it's overriden by the production track if we release something on the production track, i.e. a hotfix?

Work arounds could be:

  1. re-release the internal version with a higher version code after a release on production track has been made.
  2. not using the internal test track at all and providing the internal testers with an apk.
  3. release a seperate app for internal testing

But all these are time consuming and it makes no sense to me that there is no workflow for a parallel internal testing to a frequently updated production release.

Some suggestions on this?

Niklas Dada
  • 311
  • 4
  • 17

1 Answers1

2

I think the best approach is to continually increment version codes, for every build, and always upload a release with a higher version code, as well as use a versioning strategy that gives you release flexibility. It's unfortunately that the Play Store requires this, but I don't know of a way around it.

For example:
Your current production release has version code 123 and you're testing the next release and want to distribute for internal testing. Your next release should be incremented (e.g. version code 124), and published to internal testing. Once you're done testing and ready to release, you promote version 124 to production and prepare your next release for internal testing (and increment its version code to 125, etc.).

This is a contrived example, and versioning strategy can get really complex in a real-world example (e.g. if you ship a hotfix release straight to production to fix a critical bug), but that's more of a concern with how your versioning strategy is built and what version numbers you increment for each release.

To go even further with a real-world example:

  • We employ a versioning strategy based on Semantic Versioning (the gold standard), major.minor.patch, as the version name
  • We use a matching version code in the format MMMMmmpp, where we use 4 digits to represent the major version (M), and 2 digits each for the minor (m) and patch (p) versions.
  • App release v2.4.5 produces version code 00020405
  • Every normal release increments the minor version, hotfixes increment the patch version
Mitch Ware
  • 415
  • 1
  • 4
  • 15
  • To use the semantic version number in a MMMmmpp format as the version code is in interesting approach! This implies that it's possible to decrease version-codes on ascending releases (i.e. release hotfix for 2.0 (=00020001), while 3.0-beta (=00030000) will still be highest versioncode and therefore beta users will not have overridden their beta). I dind't know that this is working, will try it out. Thanks! But still: In my option production and beta tracks should be decoupled when it comes to auto updates. But this it not likely to be changed I guess :) – Niklas Dada Apr 15 '22 at 06:07
  • You need to ensure that hotfix releases only increment the _minor_ or _patch_ version numbers and aren't treated as a major release (since a hotfix is typically an amendment to an active release to fix unexpected behavior). Leave major releases for large breaking changes only (as explained in detail in the SemVer documentation) In your example, assuming v1.0(00010000) is the active production release, you would want your hotfix to be something like v1.1(00010100) instead of v2.0(00020000), and your new beta release can be v2.1(00020100) or v3.0(00030000) or whatever you like. – Mitch Ware Apr 27 '22 at 18:00