Release Process Guide

This guide is meant to explain the flow and rules of the release process, i.e. the period when we cut a release branch off the master branch in anticipation of releasing it to users. Release Candidates (RC) are provided to test the Release.

Before the release process

Close all the must have issues of the milestone.
1. The release process must never be started if must have issues still exist.
2. Either postpone the release or de-scope the must have issues.
Disable feature flags of any features that didn't get completed.
1. See the Cross-Team Epic Delivery Workflow document for the definition of a completed feature.
Define a priority matrix prior to the testing day.
1. This matrix should explain what constitutes a Must have, Should have and Could have bug for the release.
2. Keep in mind that only the must have issues should be worked on during the release process, all others should be moved to the next milestone.
One or more testing days should be done by the entire Status team to find any regressions before cutting.
1. The Status team should split in testing groups to help test features.
2. Testing groups should contain people from different teams to spread the knowledge.
3. Testing days should happen on days where most of the team is available.
4. Testing days must use a list of current features to test.
5. The list should include a column listing issues found and by whom.
6. The list should include an indicator whether that feature is covered by end-to-end (e2e) test and/or functional tests.
7. The list should contain a section documenting which features were recently added or refactored.
8. The recently added or refactored features should be the most tested.
9. Features on the list can be tested by multiple testing groups.
10. Testing days can happen during the release process too.

During the release process

A release branch must be created at the start of the Release Process for the Status App's master branch and status-go's develop branch
1. The format for the status-app branch is release/MAJOR.MINOR.x, eg. release/2.36.x
2. The format for the status-go branch is automatically done using the Release script. Ask a status-go maintainer to create it.
3. The status-app release branch must always point to the status-go release branch.
The first RC of the release branch should be sent to the Apple App Store immediately
1. This ensures that any question from the Apple review team can be answered and addressed as soon as possible
2. Once the release is ready, the final build will be sent to the App Store and should pass easily
All remaining issues from the milestone should be moved to the next milestone.
1. Issues needing to be fixed on the RC will be added to the current milestone.
Only bug fixes must be provided to the release branch.
Moreover, only critical bug fixes should be added to the current milestone and committed to the release branch.
1. Critical bugs are issues that affect:
  1. security
  2. potential data or funds loss
  3. crashes
  4. full regressions
Regressions should be mentioned to the QA team so that they can plan and implement e2e tests to prevent further regressions of this sort (to be implemented on master).
1. Use the needs-autotests label on the issue to flag it.
Code coverage does not need to be met on the release branch.
Features must not be allowed to be added to the release branch under any circumstances.
Fixes for issues identified during the RC phase must be worked on and committed on the release branch first.
A new RC build can be triggered every day, if there are new fixes in the release branch.
Releases and RCs must have unique semantic numbers in the VERSION file and tag.
1. Release format: 2.36.0
2. RC format: 2.36.0-rc.1
The commit updating the VERSION file must have a tag matching the same version number on it.
The release branch must be rebased on top of the master branch each time a new RC is cut
1. This ensures that the master branch stays up to date with the release branch
2. It also lowers the amount of effort needed by devs, as no one needs to cherry-pick

After the release process

A release is considered done once the builds are published to the stores and on Github, plus the release branch is fully rebased on top of master.
A new tag must be created on the master branch's latest commit with the new version and the -dev suffix. eg: 2.39.0-dev if 2.38.0 was just published.
The Status community's control node should be updated to the latest version.
The Status-Discord bridge should be updated to the latest version.
Blog posts and News Feed articles should be posted.

Frequently asked questions

When is a release ready to be cut?

A release is considered ready to be cut when all Key features are Done and when all the must have issues are closed.

A Key feature is a feature identified on the Roadmap as the most important features for that release.

A feature is considered Done when all issues of its Epic are closed. An Epic must include a testing issue, where one of the dev who worked on the issue meets with one of the designers and/or the Product Manager to demo the issue. Designers and/or the PM should open any issue they find on the new feature. Refer to the Epic Delivery Workflow guide for the full rundown.

What happens to the other features not ready at the time of the release cut?

The remaining features listed on the Roadmap on the same milestone, but that were not identified as key, will simply be pushed to the next milestone.

All new features must implement a feature flag. Therefore, unfinished features must not affect negatively the master and release branches.

Why commit to the release branch first and not master?

It is faster for the release.
Less possibilities of conflicts on the release branch.
Cherry-picked commits are often not tested. That is acceptable on master, but unacceptable on the release branch.
Issues do not close as completed when merged on the release branch. Therefore, it is easy to spot that the commit needs to be cherry-picked to master.

6.6 KiB Raw Blame History