projects / VerusCoin.git / blame
| Commit | Line | Data |
|---|---|---|
| df3005f9 JG |
1 | Hotfix Release Process |
| 2 | ====================== | |
| 3 | ||
| 24bfc7c6 JG |
4 | Hotfix releases are versioned by incrementing the build number of the latest |
| 5 | release. For example: | |
| 6 | ||
| 7 | First hotfix: v1.0.11 -> v1.0.11-1 | |
| 8 | Second hotfix: v1.0.11-1 -> v1.0.11-2 | |
| 9 | ||
| df3005f9 JG |
10 | In the commands below, <RELEASE> and <RELEASE_PREV> are prefixed with a v, ie. |
| 11 | v1.0.11 (not 1.0.11). | |
| 12 | ||
| 13 | ## Create a hotfix branch | |
| 14 | ||
| 15 | Create a hotfix branch from the previous release tag, and push it to the main | |
| 16 | repository: | |
| 17 | ||
| 18 | $ git branch hotfix-<RELEASE> <RELEASE_PREV> | |
| 19 | $ git push '[email protected]:zcash/zcash' hotfix-<RELEASE> | |
| 20 | ||
| 21 | ## Merge hotfix PRs | |
| 22 | ||
| 23 | Developer should create hotfix PRs based on the hotfix branch. Each PR should be | |
| 24 | reviewed as normal, and then the following process should be used to merge: | |
| 25 | ||
| 26 | - A CI merge build is manually run, by force-triggering the pr-merge builder | |
| 27 | with the following fields set: | |
| 28 | ||
| 29 | - Repository: https://github.com/<DevUser>/zcash | |
| 30 | - <DevUser> must be in the set of "safe" users as-specified in the CI | |
| 31 | config. | |
| 32 | - Branch: name of the hotfix PR branch (not the hotfix release branch). | |
| 33 | ||
| 34 | - A link to the build and its result is manually added to the PR as a comment. | |
| 35 | ||
| 36 | - If the build was successful, the PR is merged via the GitHub button. | |
| 37 | ||
| 38 | ## Release process | |
| 39 | ||
| 40 | The majority of this process is identical to the standard release process. | |
| 41 | However, there are a few notable differences: | |
| 42 | ||
| 43 | - When running the release script, use the `--hotfix` flag: | |
| 44 | ||
| 45 | $ ./zcutil/make-release.py --hotfix <RELEASE> <RELEASE_PREV> <APPROX_RELEASE_HEIGHT> | |
| 46 | ||
| 47 | - To review the automated changes in git: | |
| 48 | ||
| 49 | $ git log hotfix-<RELEASE>..HEAD | |
| 50 | ||
| 51 | - After the standard review process, use the hotfix merge process outlined above | |
| 52 | instead of the regular merge process. | |
| 53 | ||
| 54 | - When making the tag, check out the hotfix branch instead of master. | |
| 55 | ||
| 56 | ## Post-release | |
| 57 | ||
| 58 | Once the hotfix release has been created, a new PR should be opened for merging | |
| 59 | the hotfix release branch into master. This may require fixing merge conflicts | |
| 60 | (e.g. changing the version number in the hotfix branch to match master, if | |
| 61 | master is ahead). Such conflicts **MUST** be addressed with additional commits | |
| 62 | to the hotfix branch; specifically, the branch **MUST NOT** be rebased on | |
| 63 | master. |