hush3/doc/release-process.md

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 PROTOCOL_VERSION in src/version.h need to be increased?
  • All releases with a consensus change should increase the value by 1
  • This identifies a nodes protocol version to all other peers it connects to.
• Does MIN_PEER_PROTO_VERSION in src/version.h need to change?
  • If it does, new nodes will not be able to talk to nodes with a version less than MIN_PROTO_VERSION
• The main use of these is for newer nodes that know they do not want to talk to older nodes to prevent connecting to older nodes efficiently
• For instance, when a new release has different consensus rules than older nodes, MIN_PROTO_VERSION prevents wasting lots of network bandwidth talking to incompatible nodes which will eventually be banned for disagreeing on consensus rules

Release dependencies

Install deps on Linux:

apt-get install help2man debchange

Release process

• Update version in configure.ac and src/clientversion.h to update the hushd version
  • In src/clientversion.h you update CLIENT_VERSION_* variables. Usually you will just update CLIENT_VERSION_REVISION
  • If there is a consensus change, it may be a good idea to update CLIENT_VERSION_MINOR or CLIENT_VERSION_MAJOR
  • To make a pre-release "beta" you can modify CLIENT_VERSION_BUILD but that is rarely done in Hush world.
  • A CLIENT_VERSION_BUILD of 50 means "actual non-beta release"
  • Make sure to keep the values in configure.ac and src/clientversion.h the same. The variables are prefixed wth an underscore in configure.ac
• Run ./util/gen-manpages.sh, commit + push results
  • PROTIP: Man page creation must be done after updating the version number and recompiling and before Debian package creation
• Update checkpoints in src/chainparams.cpp via util/checkpoints.pl
  • checkpoints.pl will just generate the data you need, it must be manually copied into the correct place
  • Checkpoint are a list of block heights and block hashes that tell a full node the correct block history of the blockchain
  • Checkpoints make block verification a bit faster, because nodes can say "is this block a descendant of a checkpoint block" instead of doing full consensus checks, which take more time
  • Checkpoints also provide a bit of security against some attacks that would create malicious chainforks
• Update man pages
• Update copyright years (if applicable) with util/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
• Make Gitea release
• Make Git Tag (Gitea can do this)
• Use util/gen-linux-binary-release.sh to make a Linux release binary
• Use util/build-debian-package.sh to make an x86 Debian package for the release
• Use util/build-debian-package-ARM.sh (does this still work?) to make an ARM Debian package for the release
• Upload the debian packages to the Gitea release page, with SHA256 sums