Due to the risky nature of mobile app releases we do a fair bit of QA on our builds before submitting them to the app store. With many developers contributing to Eigen this can present a problem. If we find a bug that needs to be fixed before launch chances are while we are fixing it other code will get into the main branch besides the bug fix. If we create a new release candidate from the main branch this code also presents a risk and to be thorough we really should kick off the QA process again. This can create a constant moving target issue and cause delayed releases and take up a fair amount of engineering time. We could pause PR merging until the bug(s) are fixed but this would be needlessly disruptive to teams contributing to Eigen. What we can do instead is utilize git tags to have a pseudo code freeze on the release candidate.
If there are no launch blocking bugs found during QA this means the release candidate is set to be submitted to the app store and google play store. In the QA scripts for this release candidate you can find the version and build numbers for both the Android and iOS versions of the release candidate. Run our fastlane script to promote these exact versions to the stores
TODO: Add fastlane script example when ready
Follow our instructions LINK INSTRUCTIONS for assigning DRIs to the launch blockers and wait for PRs to come in.
Whenever we create a beta we create a corresponding git tag as part of the submission that will correspond to the build number of the submission and marks the state in the repo when the beta was submitted. For our example let's say our release candidate build is 6.4.4 (2020.5.11.15) We will want to checkout the tag 6.4.4-2020.5.11.15:
git checkout 6.4.4-2020.5.11.15
git checkout -b brian/6.4.4-release-candidate
git cherry-pick <fix-commit>
Push up the branch for posterity:
git push
Communicate with other devs that a release candidate will be deployed and they should hold off on deploying betas until a build is submitted for review.
./scripts/deploys/deploy-beta-both
Follow the instructions for deploying to app store and deploying to play store.
Make sure to QA the bug fix changes and test any code paths that may have been affected.
The changes on the release-candidate branch might be cherry-picks only, or it might be new code. Considering the release notes files are probably changed in that branch as well, it makes sense to make a PR from that release-candidate branch to main, in order to get all the changes back to main.
Here is a thread from a previous time we did this: Slack Thread 🔐