dolphin-emu
Android: Adopt a new versionCode scheme
Right now, we assign a versionCode to each Android build of Dolphin by counting the total number of git commits made. This has worked fine so far, but it won't work as-is for the new release process.
Let's say we're currently on commit 20000. If we want to create a release under the new release process, we would create a release branch, add a new commit on it that updates the release name in CMake files and so on, and create a tag for that commit. The Android build of this release commit would get the version code 20001. However, the master branch is also going to get a commit with the version code 20001 sooner or later, and this commit would be an entirely different commit than commit 20001 on the release branch. This isn't much of a problem for people downloading Dolphin from dolphin-emu.org, but it's a big problem for Google Play, as Google Play doesn't allow us to upload two builds with the same version code.
This commit makes us calculate the Android version code in a new way: The number of commits times two, and if the current build isn't a release build, plus 1. (We check whether the current build is a release build by checking whether there's a tag for the current commit.)
With this new version code scheme, the release commit described in my example would get the version code 40002, and the master commit would get the version code 40003. This lets us upload both corresponding builds to Google Play, and also lets the user switch from the release build to the development build if they would like to. (Under normal circumstances, Android forbids installing a build with an older version code than the currently installed build. Therefore, whether the 1 is added for release builds or for development builds is a decision with consequences.)
I've checked that this commit generates the expected version codes depending on whether a tag is present. @OatmealDome, please check if the version code scheme makes sense to you.
Google Play doesn't allow us to upload two builds with the same version code.
This will no longer be true shortly. Google has enabled discardable releases now.
Oh, I hadn't heard about that. But they still wouldn't allow us to have both versions uploaded and offered to users at the same time, right? That's something we ideally want to be able to do. (We already have a setup where you can opt in to a different update track to get development versions.)
But they still wouldn't allow us to have both versions uploaded and offered to users at the same time, right?
As far as I know there are no plans to change that behavior. So changing the scheme for other tracks may still make sense.
Build 20000 in Console Discard build 20000 Reupload build 20000 IFF build 20000 was not released and previously was discarded.
While I understand the problem and the proposed solution, I don't quite get the "number of commits multiplied by two" part. Wouldn't it be enough to just always add up a fixed number (e.g. 2) to all non-release builds?
E.g. if the build is a release build, set the version code as the number of commits, if it's not, set the version code as the number of commits + 2...
The commit we branch out from when making a release isn't necessarily the latest commit. For instance, let's say that we branch out from commit 20010, but the master branch already contains commits 20011, 20012 and so on all the way up to 20020. Just adding a small offset to the release build's version code would cause a collision in this case.