diff --git a/doc/RELEASE_GUIDE.md b/doc/RELEASE_GUIDE.md index 76c5333e8e..0a8eebad17 100644 --- a/doc/RELEASE_GUIDE.md +++ b/doc/RELEASE_GUIDE.md @@ -1,51 +1,46 @@ # Description -This document explains some of the steps that are involved in relseases. - -## PlayStore Metadata Updates - -You can update Play Store releae metadata using `fastlane android upload_metadata`. - -But that requires credentials necessary for accessing Play Store API. The simpler way is to edit files contained within [`fastlane/metadata`](metadata) and run the following CI job: - -https://ci.status.im/job/status-react/job/tools/job/update-playstore-metadata/ +This document explains some of the steps that are involved in releases. # Release process ## Coordination -All the coordination is done in the #release channel on discord. +All the coordination is done in the `#release` channel on discord. -## Using the script +Release readiness can be tracked by watching an appropriate milestone at [milestones](https://github.com/status-im/status-react/milestones) section in github. -You can use the script to cut a release branch: +When release is building you can check the progress in a testrail. Ask @churik for access if you don't have it + +## Preparing branches +Special branches should be created at the start of a release process. That can be done manually or with the script + +### Prepare branches with the script + +You can use the script to cut a release branch. No arguments needed, the new release version will be deducted automatically: `scripts/cut-release.sh` -This will create a branch: +Upon script call two branches will be created: +- `release/a.b.x` +- `chore/update-release-to-$version` -`release/a.b.x` +The first one is the main release branch. All bugfixes should be cherry-picked from `develop` to it. Jenkins treats that branch specially and prepares release builds from it. -Create a branch: +The second branch only updates the `VERSION` file and all you need to do is to merge it to `develop`. If you have the `gh` command installed, `cut-release` script will automatically create a PR for this. -`chore/update-release-to-$version` +### Prepare branches manually -And if you have the `gh` command installed, it will automatically create a PR for you. +#### Create a branch -## Manual steps - -### Create a branch - -First we need to create a release branch cut from develop. -The name of the branch should be `release/a.b.x` where `x` is actually `x`, not -a variable, and `a` and `b` are the `MAJOR` and `MINOR` version of the app. +First, we need to create a release branch cut from develop. +The name of the branch should be `release/a.b.x` where `x` is actually `x`, not a variable, and `a` and `b` are the `MAJOR` and `MINOR` version of the app. For example, valid branch names are: `release/1.12.x` or `release/3.12.x` - -### Update version +#### Update version We need to update the `VERSION` file to reflect the release we want to build. @@ -56,17 +51,18 @@ Jenkins will automatically build this branch and create release candidates. Those will go through the QA process and the QA team will let us know when tested successfully. -## Bugfixes before app is released +## Bugfixes before an app is released -Because both `status-react` and `status-go` might have newer commits that we don't -want to include, bug fixes should be applied separately to develop and the release branch. -The best workflow is to send a PR to develop, get it merged and the cherry-pick on the +Because both `status-react` and `status-go` might have newer commits that we don't want to include, bug fixes should be applied separately to develop and the release branch. +The best workflow is to send a PR to develop, get it merged, and the cherry-pick on the release branch. -If that's not practical for some reason (i.e develop has diverged significantly from release) +It is a release manager's responsibility to cherry-pick bugfix from `develop` to release branch. In order to do this, you should be a part of a `release group` on github. Contact @jakubgs to be added. + +If cherry-picking not practical for some reason (i.e develop has diverged significantly from release) other workflows are possible. -In order to change status-go, a similar workflow applies. +To change status-go, a similar workflow applies. First checkout the tag used in `status-go-version.json`. Create a branch on status-go named: `release/vx.y.z+hotfix.w` where @@ -99,8 +95,17 @@ And commit and push the changes # Hotfix process -The hotfix process is basically identical to the workflow above: +The hotfix process is basically identical to the workflow of a bugfix: 1) Add the changes on status-react 2) Make sure you use a hotfix branch for status-go (unless we are happy to release from develop) 3) Update the `VERSION` in status-react + +# PlayStore Metadata Updates +This section is relevant only for the marketing team, no developer participation is required. + +You can update Play Store release metadata using `fastlane android upload_metadata`. + +But that requires credentials necessary for accessing Play Store API. The simpler way is to edit files contained within [`fastlane/metadata`](metadata) and run the following CI job: + +https://ci.status.im/job/status-react/job/tools/job/update-playstore-metadata/