Release Process v22.0

[PastaPastaPasta]

Release Process

• Ensure future Release Process issues are created from the template

• Update translations, see translation_process.md.
• Update manpages, see gen-manpages.sh.

Before every minor and major release:

• Update bips.md to account for changes since the last release. (@kwvg)
• Update Security.md (@PastaPastaPasta)
• Update DIPs with any changes introduced by this release (see this pull request for an example) (@kwvg)
• Update version in configure.ac (don't forget to set CLIENT_VERSION_IS_RELEASE to true) (@PastaPastaPasta) ([DNM] [v22.0.x] chore: set release true #6413)
• Write release notes (@PastaPastaPasta)
• Update src/chainparams.cpp nMinimumChainWork with information from the getblockchaininfo rpc. (@PastaPastaPasta) (chore: update nMinimumChainWork, defaultAssumeValid, checkpointData, chainTxData for mainnet and testnet #6411)
• Update src/chainparams.cpp defaultAssumeValid with information from the getblockhash rpc. (@PastaPastaPasta) (chore: update nMinimumChainWork, defaultAssumeValid, checkpointData, chainTxData for mainnet and testnet #6411)
  • 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.
• Verify Insight works (@ktechmidas/infra)
• Ensure that governance is functional (@knst)
• Verify p2pool works (unmaintained; no responsible party)
• Tag version and push (@PastaPastaPasta )
• Validate that CI passes
• Notify mobile team of new protocol version, if applicable

Before every major release:

• Update hardcoded seeds, see this pull request for an example. (@PastaPastaPasta)
• 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). (@PastaPastaPasta)
• Update src/chainparams.cpp chainTxData with statistics about the transaction count and rate. Use the output of the getchaintxstats RPC, 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. (@PastaPastaPasta) (chore: update nMinimumChainWork, defaultAssumeValid, checkpointData, chainTxData for mainnet and testnet #6411)
• Ensure all TODOs are evaluated and resolved if needed

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

• Create windows / macOS detached signatures and commit

• Combine the all.SHA256SUMS.asc file from all signers into SHA256SUMS.asc:
• GPG sign each download / binary
• Upload zips and installers, as well as SHA256SUMS.asc from last step, to GitHub as GitHub draft release.
• Validate SHA256SUMS.asc and all binaries attached to GitHub draft release are correct
• Notarize macOS binaries
• Publish release on GitHub
• Fast-forward master branch on GitHub
• Update the dash.org download links
• Ensure that docker hub images are up to date

• Test Docker build runs without errors in Dashmate

Announce the release:

• Release on Dash forum: https://www.dash.org/forum/topic/official-announcements.54/ (necessary so we have a permalink to use on twitter, reddit, etc.)
• Prepare product brief (major versions only)
• Prepare a release announcement tweet
• Follow-up tweets with any important block heights for consensus changes
• Post on Reddit
• Celebrate

After the release:

• Submit patches to BTCPay to ensure they use latest / compatible version see Release Schedule for v18.0.0 #4211 (comment)
• Update Core and User docs (docs.dash.org)
• Test Docker build runs without error in Dashmate
• Add new Release Process items to repo Release Process document
• Merge master branch back into develop so that master could be fast-forwarded on next release again