dash/doc/release-process.md

Release Process

• Update translations, see translation_process.md.

• Update manpages, see gen-manpages.sh.

• Update release candidate version in configure.ac (CLIENT_VERSION_RC)

Before every minor and major release:

• Update bips.md to account for changes since the last release.
• Update version in configure.ac (don't forget to set CLIENT_VERSION_IS_RELEASE to true) (don't forget to set CLIENT_VERSION_RC to 0)
• Write release notes (see below)
• Update src/chainparams.cpp nMinimumChainWork with information from the getblockchaininfo rpc.
• Update src/chainparams.cpp defaultAssumeValid with information from the getblockhash rpc.
  • The selected value must not be orphaned so it may be useful to set the value two blocks back from the tip.
  • Testnet should be set some tens of thousands back from the tip due to reorgs there.
  • This update should be reviewed with a reindex-chainstate with assumevalid=0 to catch any defect that causes rejection of blocks in the past history.

Before every major release:

• Update hardcoded seeds. TODO: Give example PR for Dash
• Update src/chainparams.cpp m_assumed_blockchain_size and m_assumed_chain_state_size with the current size plus some overhead (see this for information on how to calculate them).
• Update src/chainparams.cpp chainTxData with statistics about the transaction count and rate. Use the output of the RPC getchaintxstats, see this pull request for an example. Reviewers can verify the results by running getchaintxstats <window_block_count> <window_last_block_hash> with the window_block_count and window_last_block_hash from your output.

First time / New builders

Install Guix using one of the installation methods detailed in contrib/guix/INSTALL.md.

Check out the source code in the following directory hierarchy.

cd /path/to/your/toplevel/build
git clone https://github.com/dashpay/guix.sigs.git
git clone https://github.com/dashpay/dash-detached-sigs.git
git clone https://github.com/dashpay/dash.git

Dash Core maintainers/release engineers, suggestion for writing release notes

Write release notes. git shortlog helps a lot, for example:

git shortlog --no-merges v(current version, e.g. 0.12.2)..v(new version, e.g. 0.12.3)

Generate list of authors:

git log --format='- %aN' v(current version, e.g. 0.16.0)..v(new version, e.g. 0.16.1) | sort -fiu

Tag version (or release candidate) in git

git tag -s v(new version, e.g. 0.12.3)

Setup and perform Guix builds

Checkout the Dash Core version you'd like to build:

pushd ./dash
export SIGNER='(your builder key, ie UdjinM6, Pasta, etc)'
export VERSION='(new version, e.g. 20.0.0)'
git fetch "v${VERSION}"
git checkout "v${VERSION}"
popd

Ensure your guix.sigs are up-to-date if you wish to guix-verify your builds against other guix-attest signatures.

git -C ./guix.sigs pull

Create the macOS SDK tarball: (first time, or when SDK version changes)

Create the macOS SDK tarball, see the macOS build instructions for details.

Build and attest to build outputs:

Follow the relevant Guix README.md sections:

• Building
• Attesting to build outputs

Verify other builders' signatures to your own. (Optional)

Add other builders keys to your gpg keyring, and/or refresh keys: See ../dash/contrib/builder-keys/README.md.

Follow the relevant Guix README.md sections:

• Verifying build output attestations

Next steps:

Commit your signature to guix.sigs:

pushd guix.sigs
git add "${VERSION}/${SIGNER}/noncodesigned.SHA256SUMS{,.asc}"
git commit -a
git push  # Assuming you can push to the guix.sigs tree
popd

Codesigner only: Create Windows/macOS detached signatures:

• Only one person handles codesigning. Everyone else should skip to the next step.
• Only once the Windows/macOS builds each have 3 matching signatures may they be signed with their respective release keys.

Codesigner only: Sign the macOS binary:

transfer dashcore-osx-unsigned.tar.gz to macOS for signing
tar xf dashcore-osx-unsigned.tar.gz
./detached-sig-create.sh -s "Key ID" -o runtime
Enter the keychain password and authorize the signature
Move signature-osx.tar.gz back to the guix-build host

Codesigner only: Sign the windows binaries:

tar xf dashcore-win-unsigned.tar.gz
./detached-sig-create.sh -key /path/to/codesign.key
Enter the passphrase for the key when prompted
signature-win.tar.gz will be created

Codesigner only: Commit the detached codesign payloads:

pushd ~/dashcore-detached-sigs
# checkout the appropriate branch for this release series
rm -rf *
tar xf signature-osx.tar.gz
tar xf signature-win.tar.gz
git add -A
git commit -m "point to ${VERSION}"
git tag -s "v${VERSION}" HEAD
git push the current branch and new tag
popd

Non-codesigners: wait for Windows/macOS detached signatures:

• Once the Windows/macOS builds each have 3 matching signatures, they will be signed with their respective release keys.
• Detached signatures will then be committed to the dash-detached-sigs repository, which can be combined with the unsigned apps to create signed binaries.

Create (and optionally verify) the codesigned outputs:

• Codesigning

Commit your signature for the signed macOS/Windows binaries:

pushd ./guix.sigs
git add "${VERSION}/${SIGNER}"/all.SHA256SUMS{,.asc}
git commit -m "Add ${SIGNER} ${VERSION} signed binaries signatures"
git push  # Assuming you can push to the guix.sigs tree
popd

After 3 or more people have guix-built and their results match:

Combine the all.SHA256SUMS.asc file from all signers into SHA256SUMS.asc:

cat "$VERSION"/*/all.SHA256SUMS.asc > SHA256SUMS.asc

• Upload to the dash.org server:

  1. The contents of each ./dash/guix-build-${VERSION}/output/${HOST}/ directory, except for *-debug* files.

     Guix will output all of the results into host subdirectories, but the SHA256SUMS file does not include these subdirectories. In order for downloads via torrent to verify without directory structure modification, all of the uploaded files need to be in the same directory as the SHA256SUMS file.

     The *-debug* files generated by the guix build contain debug symbols for troubleshooting by developers. It is assumed that anyone that is interested in debugging can run guix to generate the files for themselves. To avoid end-user confusion about which file to pick, as well as save storage space do not upload these to the dash.org server.

     find guix-build-${VERSION}/output/ -maxdepth 2 -type f -not -name "SHA256SUMS.part" -and -not -name "*debug*" -exec scp {} user@dash.org:/var/www/bin/dash-core-${VERSION} \;
     

  2. The SHA256SUMS file

  3. The SHA256SUMS.asc combined signature file you just created

• Announce the release:

  • Release on Dash forum: https://www.dash.org/forum/topic/official-announcements.54/

  • Optionally Discord, twitter, reddit /r/Dashpay, ... but this will usually sort out itself

  • Notify flare so that he can start building the PPAs

  • Archive release notes for the new version to doc/release-notes/ (branch master and branch of the release)

  • Create a new GitHub release with a link to the archived release notes.

  • Celebrate

Additional information

How to calculate m_assumed_blockchain_size and m_assumed_chain_state_size

Both variables are used as a guideline for how much space the user needs on their drive in total, not just strictly for the blockchain. Note that all values should be taken from a fully synced node and have an overhead of 5-10% added on top of its base value.

To calculate m_assumed_blockchain_size:

• For mainnet -> Take the size of the Dash Core data directory, excluding /regtest and /testnet3 directories.
• For testnet -> Take the size of the /testnet3 directory.

To calculate m_assumed_chain_state_size:

• For mainnet -> Take the size of the /chainstate directory.
• For testnet -> Take the size of the /testnet3/chainstate directory.

Notes:

• When taking the size for m_assumed_blockchain_size, there's no need to exclude the /chainstate directory since it's a guideline value and an overhead will be added anyway.
• The expected overhead for growth may change over time, so it may not be the same value as last release; pay attention to that when changing the variables.