2017-08-30 06:19:09 -07:00
|
|
|
Hotfix Release Process
|
|
|
|
======================
|
|
|
|
|
2017-08-30 18:05:07 -07:00
|
|
|
Hotfix releases are versioned by incrementing the build number of the latest
|
|
|
|
release. For example:
|
|
|
|
|
|
|
|
First hotfix: v1.0.11 -> v1.0.11-1
|
|
|
|
Second hotfix: v1.0.11-1 -> v1.0.11-2
|
|
|
|
|
2017-08-30 06:19:09 -07:00
|
|
|
In the commands below, <RELEASE> and <RELEASE_PREV> are prefixed with a v, ie.
|
|
|
|
v1.0.11 (not 1.0.11).
|
|
|
|
|
|
|
|
## Create a hotfix branch
|
|
|
|
|
|
|
|
Create a hotfix branch from the previous release tag, and push it to the main
|
|
|
|
repository:
|
|
|
|
|
|
|
|
$ git branch hotfix-<RELEASE> <RELEASE_PREV>
|
|
|
|
$ git push 'git@github.com:zcash/zcash' hotfix-<RELEASE>
|
|
|
|
|
2017-09-15 02:51:21 -07:00
|
|
|
## Implement hotfix changes
|
|
|
|
|
|
|
|
Hotfix changes are implemented the same way as regular changes (developers work
|
|
|
|
in separate branches per change, and push the branches to their own repositories),
|
|
|
|
except that the branches are based on the hotfix branch instead of master:
|
|
|
|
|
|
|
|
$ git checkout hotfix-<RELEASE>
|
|
|
|
$ git checkout -b <BRANCH_NAME>
|
|
|
|
|
2017-08-30 06:19:09 -07:00
|
|
|
## Merge hotfix PRs
|
|
|
|
|
2017-09-15 02:51:21 -07:00
|
|
|
Hotfix PRs are created like regular PRs, except using the hotfix branch as the
|
|
|
|
base instead of master. Each PR should be reviewed as normal, and then the
|
|
|
|
following process should be used to merge:
|
2017-08-30 06:19:09 -07:00
|
|
|
|
2017-09-15 02:51:21 -07:00
|
|
|
- A CI merge build is manually run by logging into the CI server, going to the
|
|
|
|
pr-merge builder, clicking the "force" button, and entering the following
|
|
|
|
values:
|
2017-08-30 06:19:09 -07:00
|
|
|
|
|
|
|
- Repository: https://github.com/<DevUser>/zcash
|
|
|
|
- <DevUser> must be in the set of "safe" users as-specified in the CI
|
|
|
|
config.
|
|
|
|
- Branch: name of the hotfix PR branch (not the hotfix release branch).
|
|
|
|
|
|
|
|
- A link to the build and its result is manually added to the PR as a comment.
|
|
|
|
|
|
|
|
- If the build was successful, the PR is merged via the GitHub button.
|
|
|
|
|
|
|
|
## Release process
|
|
|
|
|
|
|
|
The majority of this process is identical to the standard release process.
|
|
|
|
However, there are a few notable differences:
|
|
|
|
|
|
|
|
- When running the release script, use the `--hotfix` flag:
|
|
|
|
|
|
|
|
$ ./zcutil/make-release.py --hotfix <RELEASE> <RELEASE_PREV> <APPROX_RELEASE_HEIGHT>
|
|
|
|
|
|
|
|
- To review the automated changes in git:
|
|
|
|
|
|
|
|
$ git log hotfix-<RELEASE>..HEAD
|
|
|
|
|
|
|
|
- After the standard review process, use the hotfix merge process outlined above
|
|
|
|
instead of the regular merge process.
|
|
|
|
|
|
|
|
- When making the tag, check out the hotfix branch instead of master.
|
|
|
|
|
|
|
|
## Post-release
|
|
|
|
|
|
|
|
Once the hotfix release has been created, a new PR should be opened for merging
|
|
|
|
the hotfix release branch into master. This may require fixing merge conflicts
|
|
|
|
(e.g. changing the version number in the hotfix branch to match master, if
|
|
|
|
master is ahead). Such conflicts **MUST** be addressed with additional commits
|
|
|
|
to the hotfix branch; specifically, the branch **MUST NOT** be rebased on
|
|
|
|
master.
|