release-checklist-legacy.md

name	Legacy Release Checklist Template
about	Manual fallback checklist to create and publish a Zebra release
title	release: Zebra (version)
labels	A-release
assignees

Prepare for the Release

• Make sure there has been at least one successful full sync test in the main branch since the last state change, or start a manual full sync.

Checkpoints

For performance and security, we want to update the Zebra checkpoints in every release.

• You can copy the latest checkpoints from CI by following the zebra-checkpoints README.

Missed Dependency Updates

Sometimes dependabot misses some dependency updates, or we accidentally turned them off.

This step can be skipped if there is a large pending dependency upgrade. (For example, shared ECC crates.)

Here's how we make sure we got everything:

• Run cargo update on the latest main branch, and keep the output
• If needed, add duplicate dependency exceptions to deny.toml
• If needed, remove resolved duplicate dependencies from deny.toml
• Open a separate PR with the changes
• Add the output of cargo update to that PR as a comment

Summarise Release Changes

These steps can be done a few days before the release, in the same PR:

Change Log

Important: This legacy checklist is for manual fallback releases when the automated release-plz workflow is not usable. Keep all changelog edits in the release branch until the release PR is merged.

Changelog entries are authored and curated per PR in the [Unreleased] section of CHANGELOG.md, so the entries for this release are already written. We follow the Keep a Changelog format.

To finalize the change log:

• Rename the [Unreleased] heading to ## [Zebra <version>](https://github.com/ZcashFoundation/zebra/releases/tag/v<version>) - <date>
• Read through the finalized entries and confirm each one reads well for Zebra users and sits in the right category, fixing anything that slipped past per-PR review

README

README updates can be skipped for urgent releases.

Update the README to:

• Remove any "Known Issues" that have been fixed since the last release.
• Update the "Build and Run Instructions" with any new dependencies. Check for changes in the Dockerfile since the last tag: git diff <previous-release-tag> docker/Dockerfile.
• If Zebra has started using newer Rust language features or standard library APIs, update the known working Rust version in the README, book, and Cargo.tomls

You can use a command like:

fastmod --fixed-strings '1.58' '1.65'

Create the Release PR

• Push the updated changelog and README into a new branch for example: bump-v1.0.0 - this needs to be different to the tag name
• Create a release PR by adding &template=release-checklist-legacy.md to the comparing url (Example).
• Freeze main in the Merge Freeze dashboard.
• Remove every active non-release entry from GitHub's merge queue so the freeze takes effect immediately.
• Use Merge Freeze's Unblock 1 pull request action for this release PR. Freezing and thawing write a status to every open pull request at roughly a second each, so give them time to land.
• Add the A-release tag to the release pull request in order for the check-no-git-dependencies to run.

Zebra git sources dependencies

• Ensure the check-no-git-dependencies check passes.

This check runs automatically on pull requests with the A-release label. It must pass for crates to be published to crates.io. If the check fails, you should either halt the release process or proceed with the understanding that the crates will not be published on crates.io.

Update Versions and End of Support

Update Zebra Version

Zebra follows semantic versioning. Semantic versions look like: MAJOR.MINOR.PATCH[-TAG.PRE-RELEASE]

Choose a release level for zebrad. Release levels are based on user-visible changes from the changelog:

• Mainnet Network Upgrades are major releases
• significant new features or behaviour changes; changes to RPCs, command-line, or configs; and deprecations or removals are minor releases
• otherwise, it is a patch release

Update Crate Versions and Crate Change Logs

If you're publishing crates for the first time, log in to crates.io, and make sure you're a member of owners group.

Crate changelog entries are authored per PR in each crate's CHANGELOG.md [Unreleased] section, and breaking changes are declared per PR with a conventional-commit !. The release level for each crate follows those markers: a ! since the previous release means a major release, a new API means a minor release, otherwise a patch release.

• Determine which crates require release. Run git diff --stat <previous_tag> and enumerate the crates that had changes.
• For each crate that requires a release:
  • Rename the [Unreleased] heading in the crate CHANGELOG.md to the new version, and confirm the already-authored entries read correctly for a crate consumer.
  • Bump the crate version:

cargo release version --verbose --execute --allow-branch '*' -p <crate> patch # [ major | minor ]
# zebrad only
cargo release replace --verbose --execute --allow-branch '*' -p zebrad

• Commit and push the above version changes to the release branch.

Verify the API bump (backstop)

The per-PR cargo-semver-checks CI gate already enforces that breaking API changes carry a conventional-commit !. Run the manual checks below as a backstop, or when the gate could not run (for example, the previous release was yanked, which semver-checks cannot diff against):

• Update (or install) semver-checks: cargo +stable install cargo-semver-checks --locked
• Update (or install) public-api: cargo +stable install cargo-public-api --locked
• For each crate, confirm the chosen release level matches the API surface: cargo semver-checks -p <crate> --default-features. List the full API diff with cargo public-api diff latest -p <crate> -sss, or run ziff <previous_tag> once to get the per-crate diff plus dependency and (with --with-values) const/static value and doc changes in one pass.

Update Initial Minimum Network Protocol Version

• If this release should stop connecting to older peers, update INITIAL_MIN_NETWORK_PROTOCOL_VERSION in zebra-network/src/constants.rs.

Update End of Support

The end of support height is calculated from the current blockchain height:

• Find where the Zcash blockchain tip is now by using a Zcash Block Explorer or other tool.
• Replace ESTIMATED_RELEASE_HEIGHT in end_of_support.rs with the height you estimate the release will be tagged.

Optional: calculate the release tagging height

• Find where the Zcash blockchain tip is now by using a Zcash Block Explorer or other tool.
• Add 1152 blocks for each day until the release
• For example, if the release is in 3 days, add 1152 * 3 to the current Mainnet block height

Update the Release PR

• Push the version increments and the release constants to the release branch.

Publish the Zebra Release

Create the GitHub Pre-Release

• Wait for all the release PRs to be merged
• Create a new GitHub release from the releases page
• Set the tag name to the version tag, for example: v1.0.0
• Set the release to target the main branch
• Set the release title to Zebra followed by the version tag, for example: Zebra 1.0.0
• Copy the final changelog you created into the release description; starting just after the title ## [Zebra ... of the current version being released, and ending just before the title of the previous release.
• Mark the release as 'pre-release', until it has been built and tested
• Publish the pre-release to GitHub using "Publish Release"

Test the Pre-Release

• Wait until the Docker binaries have been built on main, and the quick tests have passed:
  • zfnd-ci-integration-tests-gcp.yml
• Wait until the pre-release deployment machines have successfully launched

Publish Release

• Publish the release to GitHub by disabling 'pre-release', then clicking "Set as the latest release"

Publish Crates

• Run cargo login
• It is recommended that the following step be run from a fresh checkout of the repo, to avoid accidentally publishing files like e.g. logs that might be lingering around
• Publish the crates to crates.io; edit the list to only include the crates that have been changed, but keep their overall order:

for c in zebra-test tower-fallback zebra-chain tower-batch-control zebra-node-services zebra-script zebra-state zebra-consensus zebra-network zebra-rpc zebra-utils zebrad; do cargo release publish --verbose --execute -p $c; done

• Check that Zebra can be installed from crates.io: cargo install --locked --force --version <version> zebrad && ~/.cargo/bin/zebrad and put the output in a comment on the PR.

Publish Docker Images

• Wait for the the Docker images to be published successfully.
• Wait for the new tag in the dockerhub zebra space
• Thaw main in the Merge Freeze dashboard, if it was frozen there.

Release Failures

If building or running fails after tagging:

Tag a new release, following these instructions...

1. Fix the bug that caused the failure
2. Start a new patch release
3. Skip the Release Preparation, and start at the Release Changes step
4. Update CHANGELOG.md with details about the fix
5. Follow the release checklist for the new Zebra version