Alpha/beta release best practices

[mnalis]

• when making an alpha of beta release, it would be useful to mark it is as such.

  for example, when 5.2.0-alpha was released, it was correctly tagged in git tag as 5.2.0-alpha, but its versionName in app/build.gradle was set to 5.2.0.

  It would've been much better if it also were set to 5.2.0-alpha, so users will know it is an an alpha (both in the app, and when viewing app versions on app stores etc.)

• when making a regular release after alpha/beta (actually when making a new release of any kind), we should always increase at least the versionCode in app/build.gradle (and likely versionName too, see above)

  that didn't happen with 5.2.0 release, but instead both 5.2.0-alpha and 5.2.0 release had same versionCode=1049.

  That is bad for multiple reasons:

  • users who have installed alpha won't be offered (and maybe be able at all?) to upgrade to the release (as it looks like same version)
  • f-droid at least might have issues with different releases claiming to be the same, so might have problems to build/publish the release at all (I'm trying to handle that at https://gitlab.com/fdroid/fdroiddata/-/merge_requests/21058)

[RitikaPahwa4444]

users who have installed alpha won't be offered (and maybe be able at all?) to upgrade to the release (as it looks like same version)

This was my first release on Google Play, and I observed the review process is quite strict. I promoted the same APK on Google Play, so it used the same version code. Any idea what would be the impact on the Google Play review process if I upload a new APK instead of promoting the tested variant?

[mnalis]

I promoted the same APK on Google Play, so it used the same version code

So, IIUC, there was 5.2.0 on Google Play with versionCode 1049 updated on 2025-03-22, which I assume was the alpha (due to the date). I don't know about Google Play policies, but it is likely that pushing different version with same Name/Code would be problematic.

For F-droid, I've just had a word that it is not possible, so they're going to be publishing alpha as 5.2.0.

Any idea what would be the impact on the Google Play review process if I upload a new APK instead of promoting the tested variant?

I'm not sure, but such exceptions might cause more trouble than help, esp. with Google Play where it is slow and hard to talk to actual humans. As the changes between alpha and 5.2.0 release are not much (just few translations?), perhaps it would be better not to touch it any more?

---

I personally think it would be best to work on releasing 5.2.1 soon, even with it only having some only some minor code changes, as that should work around the issue, with minimum risk of creating other problems.

But it would be good to gather few other opinions of more experienced persons who had actually worked Google Play before changing anything. Rushing is rarely a good strategy 😸

[RitikaPahwa4444]

My only concerns with bumping up the version code while moving from alpha->beta->production on Google Play are longer review processes and the possibility of getting the newer one rejected somehow.

I personally think it would be best to work on releasing 5.2.1 soon

Planned on a monthly release cycle with a few milestone items accomplished, but if the versioning is creating a problem on F-Droid, I'll release it sooner.

[misaochan]

I haven't done releases for a while, but when I used to do them, we would just promote directly from beta to production. versionCode increase does not happen in that case because it was unnecessary when using the "promote to production" functionality on the Play Store console. It's true that beta testers don't get the "update", but that's because they have the exact same version of the app as the production users do, they just had it sooner.

Some beta versions did not make it to production, so in cases where a newer beta was uploaded without the previous one making it to production, the versionCode was increased (because it's a completely different .apk). In those cases production users will "skip" a number.

So essentially the question is: Was there a difference at all in the .apk uploaded to alpha/beta and the one promoted to production? AFAIK, if yes: then it should have been a different versionCode, if not: then no.

Maybe @nicolas-raoul or @sivaraam can chime in since they have done this more recently than I.

[RitikaPahwa4444]

So essentially the question is: Was there a difference at all in the .apk uploaded to alpha/beta and the one promoted to production? AFAIK, if yes: then it should have been a different versionCode, if not: then no.

No, there was no difference this time, and I had no issues in the Google Play process. It's regarding the alpha/beta best practices being discussed in this issue - should we have a different version code for Google Play as well or not. It would be inconsistent from the one released on Play Store if done just on GitHub.

I saw a few other pre releases sharing the same version code, how did we handle them back then?

[mnalis]

So essentially the question is: Was there a difference at all in the .apk uploaded to alpha/beta and the one promoted to production? AFAIK, if yes: then it should have been a different versionCode, if not: then no.

No, there was no difference this time,

Uh, are you sure? v5.2.0-alpha was tagged on commit 2e05a58, then there was another commit at 5a5e660, and then there was another commit 669f304 on which 5.2.0 (release) was tagged .

Since those commits are not the same, at least universal .apk files will differ (the differences are only in string resources in this case, but still, 5.2.0 (release) application will look different to users than 5.2.0-alpha)

I haven't done releases for a while, but when I used to do them, we would just promote directly from beta to production. versionCode increase does not happen in that case because it was unnecessary.

Yes, it is fine there, as alpha version would be bit-wise identical to the release version, so only difference would be in name. This is not a case here, as the 5.2.0-alpha and 5.2.0 will look different to some users (depending on the selected language)

Planned on a monthly release cycle with a few milestone items accomplished, but if the versioning is creating a problem on F-Droid, I'll release it sooner.

probably no need (as noted, there are not that many changes between 5.2.0 alpha and release), and monthly release cycle sounds great! But we'll see in few days how does the F-droid handle it (they should publish 5.2.0-alpha if everything else works; but there were some previous issues with NDK mismatch which were hopefully corrected)

[RitikaPahwa4444]

Uh, are you sure? v5.2.0-alpha was tagged on commit 2e05a58, then there was another commit at 5a5e660, and then there was another commit 669f304 on which 5.2.0 (release) was tagged

I think I accidentally used a different commit on GitHub😕 Thank you for checking! 2e05a58 was to be tagged as release version too.

[misaochan]

No worries at all @RitikaPahwa4444 , these things happen. :) I think there's no need to try to go back and re-release the last one. Just keep in mind for the next release that it should be the same APK. Basically, if you have to upload the APK to the Play Store again (instead of just clicking "Promote"), the versionCode needs to be incremented.

Thanks for handling the release!

[nicolas-raoul]

It would be great to document the workflow at https://github.com/commons-app/commons-app-documentation/blob/master/android/Project-maintenance.md to ease maintenance. 🙂

[sivaraam]

So essentially the question is: Was there a difference at all in the .apk uploaded to alpha/beta and the one promoted to production? AFAIK, if yes: then it should have been a different versionCode, if not: then no.

Just for the record, this is precisely how it was when I was handling the release too. So, your observation is correct w.r.t Google Play.

I saw a few other pre releases sharing the same version code, how did we handle them back then?

I have myself also goofed up the pre-release a bit in the past. So, you might want to be specific about which one you used as a reference. X-[

Sorry for not setting too many good examples for the beta release.

[RitikaPahwa4444]

I referred to the first pre-release that I found on scrolling (v4.2.0-beta), but I think this confusion started because I released a different commit while I was not intending to.

users who have installed alpha won't be offered (and maybe be able at all?) to upgrade to the release (as it looks like same version)

Since I was under the impression that I released the same code both the times, this left me bewildered (why would users expect an upgrade when there were literally no changes!😅).

Thank y'all for elaborating, I'll take care from the next time.

[sivaraam]

I referred to the first pre-release that I found on scrolling (v4.2.0-beta), but I think this confusion started because I released a different commit while I was not intending to.

Got it. That was a bit tricky one. But if you closely observe the v4.2.0-beta was followed by a v4.2.1 which is the one that hit production with a bumped versionCode. There is some related discussion here. Sharing just for reference.