Describe and simplify the release process (#1322)
This commit is contained in:
Adam Babik
GitHub
parent
74cb16c456
commit
7fb2755f6b
20
README.md
20
README.md
|
|
@ -5,26 +5,10 @@
|
|||
|
||||
# Docs
|
||||
|
||||
- [How To Build](https://docs.status.im/docs/build_status_go.html)
|
||||
- [How To Build](https://status.im/build_status/status_go.html)
|
||||
- [How To Contribute](CONTRIBUTING.md)
|
||||
- [How To Release](RELEASING.md)
|
||||
|
||||
# License
|
||||
|
||||
[Mozilla Public License 2.0](https://github.com/status-im/status-go/blob/develop/LICENSE.md)
|
||||
|
||||
### Releasing
|
||||
|
||||
To create a release, first increase the `VERSION` file according to semantic versioning.
|
||||
|
||||
You can then build the artifacts for the specific platform.
|
||||
|
||||
Once done, you can run:
|
||||
|
||||
`make prepare-release`
|
||||
|
||||
and
|
||||
|
||||
`make release release_branch={{release_branch}}`
|
||||
|
||||
Where `release_branch` is the branch you are targeting.
|
||||
You will also need to specify some form of credentials, `GITHUB_TOKEN` environment variable for example.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,55 @@
|
|||
# Release Process of status-go
|
||||
|
||||
The release process describes creating a release on Github. Each release consists of a new tag and assets which are builds for various environments but not only.
|
||||
|
||||
The process is automated and, even though it's possible to run manually, should always be triggered using [our Jenkins job](https://ci.status.im/job/status-go/job/parallel/).
|
||||
|
||||
## Versioning
|
||||
|
||||
We use [semver](https://semver.org/) but as we do not have a stable version yet, it's a bit skewed.
|
||||
|
||||
We use `0` as the MAJOR version and bump only MINOR when there are breaking changes and PATCH when there are no breaking changes.
|
||||
|
||||
Additionally, a pre-release can be created and the version can look like as complicated as this:
|
||||
```
|
||||
0.MINOR.PATCH-beta.INDEX.GIT_SHA
|
||||
```
|
||||
|
||||
## Releasing from a branch
|
||||
|
||||
TODO: create a script that can do that instead of manual work.
|
||||
|
||||
1. Make sure that your branch is rebased on `develop`,
|
||||
1. Change `VERSION` file content to `0.X.Y-beta.Z.$GIT_SHA` where `GIT_SHA` is the commit you want to release,
|
||||
1. Go to [Jenkins job](https://ci.status.im/job/status-go/job/parallel/) and use your branch. NOTE: do **not** select "RELEASE".
|
||||
|
||||
**NOTE**: remember to change `VERSION` content back before merge.
|
||||
|
||||
## Releasing pre-release from develop
|
||||
|
||||
TODO: create a script that can do that instead of manual work.
|
||||
|
||||
1. Pull `develop` branch,
|
||||
1. Bump `Z` (`0.X.Y-beta.Z`) in the current version (`VERSION` file),
|
||||
1. Commit and push the change,
|
||||
1. Go to [Jenkins job](https://ci.status.im/job/status-go/job/parallel/) and use develop branch. NOTE: do not select "RELEASE".
|
||||
|
||||
## Releasing from develop (regular release)
|
||||
|
||||
TODO: create a script that can do that instead of manual work.
|
||||
|
||||
1. Pull `develop` branch,
|
||||
1. Checkout a new branch `release/0.X`,
|
||||
1. Remove `-beta.Z` suffix from the current version (`VERSION` file),
|
||||
1. Commit and push the change,
|
||||
1. Checkout develop branch, bump `X`, reset `Z` to `0` and commit to develop,
|
||||
1. Go to [Jenkins job](https://ci.status.im/job/status-go/job/parallel/), select "RELEASE" and use `release/0.X` branch.
|
||||
|
||||
## Releasing from develop (a hot-fix)
|
||||
|
||||
TODO: create a script that can do that instead of manual work.
|
||||
|
||||
1. Checkout a release branch you want to hot fix (branch have a name `release/0.X`),
|
||||
1. Bump `Y` (`0.X.Y`) in the current version (`VERSION` file),
|
||||
1. Commit and push the change to `release/0.X` branch,
|
||||
1. Go to [Jenkins job](https://ci.status.im/job/status-go/job/parallel/), select "RELEASE" and use `release/0.X` branch name.
|
||||
Loading…
Reference in New Issue