Release Checklist

Preparing the release

  • Fetch the tip of master:

    $ git checkout master
    $ git pull
  • Make sure cardano-wallet points to correct revisions of dependencies in stack.yaml and cabal.project.

    Verify that the content of [stack.yaml][] and [cabal.project][] correspond to the cardano-node version.

    Verify that target repositories point to appropriate revisions for persistent, cardano-addresses, bech32, …)

  • Create a new branch for the release:

    $ git checkout -b your-name/vYYYY-MM-DD/bump-release
  • From the root of the repository, run:

    $ ./scripts/

    This will bump the version in .cabal and .nix files, and the swagger spec files, and generate release notes.

    💡 Note: If you get GitHub API rate limit errors, you can set the GITHUB_API_TOKEN environment variable. To create a personal access token, go to your Github Settings. No scope is required for this token, only public access (as it is simply used to read publicly available data from the Github API).

  • Verify that the script modified the compatibility matrix in correctly.

  • Open a pull request to submit the modified files.

  • Get it merged.

  • Create and push a signed release tag on the HEAD of master.

    $ git tag -s -m vYYYY-MM-DD vYYYY-MM-DD
    $ git push origin refs/tags/vYYYY-MM-DD

    Where YYYY-MM-DD should be replaced by the actual date of the release.

    This will trigger a release build on CI (GitHub Actions).

  • Wait for the release build to finish and then check that build artifacts have been published on the GitHub release page.

Create the release notes

  • Write release notes in the release page using the previously generated release notes. Fill in the empty sections.

  • Remove items that are irrelevant to users (e.g. pure refactoring, improved testing)

  • Make sure the items that the script put in the “Unclassified” section are moved to an appropriate section (or removed).

  • You may want to polish the language of the PR titles to make it sound like actual release notes.

Verify release artifacts

Manual ad-hoc verifications

  • Execute all manual scenarios on the binaries to be released.

  • Verify that sensitive fields listed in Cardano/Wallet/Api/Server are still accurate and aren’t missing any new ones.

    sensitive =
        [ "passphrase"
        , "old_passphrase"
        , "new_passphrase"
        , "mnemonic_sentence"
        , "mnemonic_second_factor"
  • Verify latest buildkite nightly and make sure the results are fine. Benchmark charts may be helpful in analysis.


  • Once everyone has signed off (i.e. Tech lead, QA & Release manager), publish the release draft.

  • Add the release to the automated migration tests (keep only the last 10 versions). See the header of the file as to how to generate the SHA256 hashes.