Skip to content

Release Process

Before Release

  1. Check configuration
    • Check features planned for the release are implemented and documented (or more informally, that the Release Manager agrees it is feature complete)
    • Check that finished tasks / tickets are marked as resolved
  2. Verify tests passed
    • Any known issues or limitations should be documented in release notes
    • Known bugs should have tickets
    • Run arc lint $(find contrib/) and check there is no linter error
    • Run arc lint *.md $(find doc/) from top level folder and check there are no new linter error (except a suggestion to fix 'reenable' spelling in an URL in doc/, a suggestion which should be ignored.
    • Run arc lint on any Markdown or other text documents within src/ and depends/ which are not from third-party sources. "Our" documents within src/ and depends/ should all be clean. NOTE: We do not run arc lint on the other source files anymore.
    • Ensure that bitcoind and bitcoin-qt run with no issue on all supported platforms. Manually test bitcoin-qt by sending some transactions and navigating through the menus.
  3. Update the documents / code which needs to be updated every release
    • Update and to account for changes since the last release.
    • (major releases) Update BLOCK_CHAIN_SIZE to the current size plus some overhead.
    • Update seeds as per contrib/seeds/
    • Update src/chainparams.cpp m_assumed_blockchain_size and m_assumed_chain_state_size with the current size plus some overhead.
    • Update the chain parameters (see contrib/devtools/chainparams/
    • Run the refresh procedure for documents that are automatically generated
    • Check that is complete, and fill in any missing items.
  4. Add git tag for release a. Create the tag: git tag vM.m.r (M = major version, m = minor version, r = revision) b. Push the tag to GitLab:

    git push <gitlab remote> master
    git push <gitlab remote> vM.m.r
  5. Increment version number for the next release in:

    • doc/ (and copy existing one to versioned doc/release-notes/*.md)
    • CMakeLists.txt
    • contrib/seeds/ (only after a new major release)


  1. Create Gitian Builds (see
  2. Verify matching Gitian Builds, gather signatures
  3. Verify IBD bith with and without -checkpoints=0 -assumevalid=0
  4. Upload Gitian Builds to
  5. Create a release on our GitHub mirror: contrib/release/ -a <path to release binaries> -t <release tag> -o <file containing your Github OAuth token>
  6. Create Ubuntu PPA packages: Maintainers need to clone packaging and follow instructions to run in that repository.
  7. Notify maintainers of AUR and Docker images to build their packages. They should be given 1-day advance notice if possible.

After Release

  1. Update version number on
  2. Publish signed checksums (various places, e.g. blog, reddit, etc. etc.)
  3. Announce Release:
    • Reddit
    • Twitter @bitcoincashnode
    • Public slack channels friendly to Bitcoin Cash Node announcements