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:
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?
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:
major.minor.patch, as the version nameMMMMmmpp, where we use 4 digits to represent the major version (M), and 2 digits each for the minor (m) and patch (p) versions.