mirror of
https://github.com/status-im/status-react.git
synced 2025-01-22 16:59:40 +00:00
Update release guide
Signed-off-by: Volodymyr Kozieiev <vkjr.sp@gmail.com>
This commit is contained in:
parent
0b8509949a
commit
8628cbbf76
@ -1,51 +1,46 @@
|
|||||||
# Description
|
# Description
|
||||||
|
|
||||||
This document explains some of the steps that are involved in relseases.
|
This document explains some of the steps that are involved in releases.
|
||||||
|
|
||||||
## 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/
|
|
||||||
|
|
||||||
# Release process
|
# Release process
|
||||||
|
|
||||||
## Coordination
|
## 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`
|
`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
|
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.
|
||||||
### 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.
|
|
||||||
|
|
||||||
For example, valid branch names are:
|
For example, valid branch names are:
|
||||||
|
|
||||||
`release/1.12.x` or `release/3.12.x`
|
`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.
|
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
|
Those will go through the QA process and the QA team will let us know when
|
||||||
tested successfully.
|
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
|
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.
|
||||||
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
|
||||||
The best workflow is to send a PR to develop, get it merged and the cherry-pick on the
|
|
||||||
release branch.
|
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.
|
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`.
|
First checkout the tag used in `status-go-version.json`.
|
||||||
|
|
||||||
Create a branch on status-go named: `release/vx.y.z+hotfix.w` where
|
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
|
# 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
|
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)
|
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
|
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/
|
||||||
|
Loading…
x
Reference in New Issue
Block a user