59 lines
2.5 KiB
Markdown
59 lines
2.5 KiB
Markdown
# Hush Release Process
|
|
|
|
## High-Level Philosophy
|
|
|
|
Beware of making high-risk changes (such as consensus changes, p2p layer changes and wallet/transaction changes) too close to a new release, because they will not get as much testing as they should. Don't merge large branches which haven't undergone lots of testing just before a release.
|
|
|
|
## Check for changes on master that should be on dev
|
|
|
|
Often there are trivial changes made directly on master, such as documentation changes. In theory, no code changes should happen on master without being on dev first, but it's better to be safe than sorry. We want the dev branch which undergoes testing to be as close as possible to what the master branch will become, so we don't want to merge dev into master and just assume everything works. So it's best to merge the master branch into dev just before merging the dev branch into master.
|
|
|
|
To check if the master branch has any changes that the dev branch does not:
|
|
|
|
```
|
|
# this assumes you are working with https://git.hush.is/hush/hush3 as your remote
|
|
git checkout dev
|
|
git pull # make sure dev is up to date
|
|
git checkout master
|
|
git pull # make sure master is up to date
|
|
git diff dev...master # look at the set of changes which exist in master but not dev
|
|
```
|
|
|
|
If the last command has no output, congrats, there is nothing to do. If the last command has output, then you should merge master into dev:
|
|
|
|
```
|
|
git checkout dev
|
|
git merge --no-ff master # using the default commit message is fine
|
|
git push
|
|
```
|
|
|
|
The `--no-ff` flag above makes sure to make a merge commit, no matter what, even if a "fast forward" could be done. For those in the future looking back, it's much better to see evidence of when branches were merged.
|
|
|
|
|
|
### Git Issues
|
|
|
|
Look for Git issues that should be fixed in the next release. Especially low-risk and simple things, like documentation changes, improvements to error messages and RPC help output.
|
|
|
|
### Pre-release checklist:
|
|
* Is this release changing consensus rules? Definitely update protocol version.
|
|
|
|
### Protocol Safety Checks:
|
|
|
|
* Does MIN_PROTO_VERSION need to change?
|
|
* If it does, new nodes will not be able to talk to nodes with a version less than MIN_PROTO_VERSION
|
|
|
|
## Release dependencies
|
|
|
|
Install deps on Linux:
|
|
|
|
apt-get install help2man debchange
|
|
|
|
## Release process
|
|
|
|
- Update checkpoints
|
|
- Update man pages
|
|
- Update copyright years (if applicable) with replace.pl
|
|
- Do a fresh clone and fresh sync with new checkpoints
|
|
- Stop node, wait 20 minutes, and then do a partial sync with new checkpoints
|
|
|