Preparing the release
Fetch the tip of
$ git checkout master $ git pull
Verify that the content of [
stack.yaml] and [
cabal.project] correspond to the
Verify that target repositories point to appropriate revisions for
Create a new branch for the release:
$ git checkout -b your-name/vYYYY-MM-DD/bump-release
From the root of the repository, run:
This will bump the version in
.nixfiles, and the swagger spec files, and generate release notes.
💡 Note: If you get GitHub API rate limit errors, you can set the
GITHUB_API_TOKENenvironment 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 README.md correctly.
Open a pull request to submit the modified files.
Get it merged.
Create and push a signed release tag on the
$ git tag -s -m vYYYY-MM-DD vYYYY-MM-DD $ git push origin refs/tags/vYYYY-MM-DD
YYYY-MM-DDshould 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
Verify that the documentations have been correctly exported on gh-pages
Make sure the Command-Line Interface manual is up to date.
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" ]
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.