hush
/
hush
8
0
Fork 1
Code Issues Pull Requests Projects Releases Wiki Activity
Original HUSH source code based on ZEC 1.0.8 . For historical purposes only! https://hush.is
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
11262 Commits
32 Branches
8 Tags
52 MiB
 
 
 
 
 
 
Branch: master
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'master'
${ noResults }
hush/doc/hotfix-process.md

2.6 KiB
Raw Permalink Blame History

Hotfix Release Process

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

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>

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>

Merge hotfix PRs

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:

  • 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:

    • 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.