Duplicated app releases

[jeroenpg]

Describe the bug Currently the android-master workflow creates a release for tagged builds. Once iOS automated builds is finished it will create a release for iOS aswell. This would cause two releases, one for android, one for ios respectively. We don't want this behavior do we? I guess we could create a release before the android & ios workflows?

To Reproduce Steps to reproduce the behavior:

1. Create a tagged build
2. Wait for builds to finish
3. See two new releases in this repo, one for android, one for ios

Expected behavior I would expect one release with an IPA and APK attached

[haveyaseen]

Yeah, releases are broken right now anyways. Might be worth it to fix this in the same run.

[joernb]

I guess, that depends on wether a tag should create a release for all platforms (Release 1.2.3) or only for one (Android 1.2.3).

Having one release for all platforms on every tag creation might be too tightly coupled together. As you pointed out in the chat, this might trigger Android builds although only iOS changes were made for example. If those pipelines should publish to the same GitHub release draft, there needs to be some logic to check if a particular release already exists or needs to be created or the creation needs to be done by another pipeline, that just prepares the release draft for the platform pipelines.

Having platform-specific releases on GitHub (e.g. Android 1.2.3) allows better isolation between pipelines IMHO. Every pipeline can just create its platform-specific release. That allows for more flexibility in the build process. It requires to set platform-specific tags like 1.2.3-android or 1.2.3-ios that will only trigger the pipeline of the platform. I think, we might be better of with this approach for now.

[assert-not-singularity]

How do we deal with the version numbers for the different platforms then? Are these synchronized, so we always have the same version on Android and iOS or decoupled?

Having the same version number on both platforms could lead to the following situation: There is a new feature in the next release which only affects Android for some reason (calling a new API which has no equivalent on iOS). This would raise the version from 1.1.4 to 1.2.0 for example. Should we then just leave out this version on iOS and call the next version with a new feature on both platforms 1.3.0, effectively skipping one minor release? Should we raise the version anyway without having new features in the build?

Alternatively, we can raise version numbers independently. Then some day we might have the situation where the newest version for iOS is 1.7.2 and the newest for Android is 1.5.8 while feature A was brought to iOS with 1.4.0 but to Android with 1.2.0.

[jeroenpg]

@assert-not-singularity I think raising versions independently is the way to go. Especially when our apps are deployed to the app stores. I don't think we want to go through the apple review process every time we update the android app. Changes that don't affect the other platform are bound to happen, considering the amount of native code we are actually using/ going to use.