2.0 KiB

Raw Blame History

Hotfix Release Process

In the commands below, 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>

Merge hotfix PRs

Developer should create hotfix PRs based on the hotfix branch. Each PR should be reviewed as normal, and then the following process should be used to merge:

A CI merge build is manually run, by force-triggering the pr-merge builder with the following fields set:
- Repository: https://github.com//zcash
  - 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_PREV> <APPROX_RELEASE_HEIGHT>
To review the automated changes in git:

$ git log hotfix-..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.

2.0 KiB Raw Blame History