zecfoundation
/
zebra
mirror of https://github.com/ZcashFoundation/zebra.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zebra/.github/PULL_REQUEST_TEMPLATE/release-checklist.md

8.3 KiB
Raw Blame History

name about title labels assignees
Release Checklist Template Checklist of versioning to create a taggable commit for Zebra

Prepare for the Release

These release steps can be done a week before the release, in separate PRs. They can be skipped for urgent releases.

Checkpoints

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

Missed Dependency Updates

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

Here's how we make sure we got everything:

  • Run cargo update on the latest main branch, and keep the output
  • If needed, update deny.toml
  • Open a separate PR with the changes
  • Add the output of cargo update to that PR as a comment

Make Release Changes

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

  • Make sure the PRs with the new checkpoint hashes and missed dependencies are already merged

Versioning

How to Increment Versions

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

Choose a release level for zebrad based on the changes in the release that users will see:

  • Mainnet Network Upgrades are major releases
  • new features, large changes, deprecations, and removals are minor releases
  • otherwise, it is a patch release

Zebra's Rust API doesn't have any support or stability guarantees, so we keep all the zebra-* and tower-* crates on a beta pre-release version.

Update Crate Versions

If you're publishing crates for the first time:
  • Update crate versions and do a release dry-run
    • cargo clean (optional)
    • cargo release version --verbose --execute --workspace --exclude zebrad beta
    • cargo release version --verbose --execute --package zebrad [ major | minor | patch ]
    • cargo release publish --verbose --dry-run --workspace
  • Commit the version changes to your release PR branch using git: cargo release commit --verbose --execute --workspace

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'

Change Log

Important: Any merge into main deletes any edits to the draft changelog. Once you are ready to tag a release, copy the draft changelog into CHANGELOG.md.

We use the Release Drafter workflow to automatically create a draft changelog. We follow the Keep a Changelog format.

To create the final change log:

  • Copy the latest draft changelog into CHANGELOG.md (there can be multiple draft releases)
  • Delete any trivial changes
    • Put the list of deleted changelog entries in a PR comment to make reviewing easier
  • Combine duplicate changes
  • Edit change descriptions so they will make sense to Zebra users
  • Check the category for each change
    • Prefer the "Fix" category if you're not sure

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 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
  • 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

Create the Release PR

  • Push the version increments, the updated changelog, and the release constants into a 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.md to the comparing url (Example).
  • Freeze the batched queue using Mergify.
  • Mark all the release PRs as Critical priority, so they go in the urgent Mergify queue.

Release Zebra

Create the GitHub Pre-Release

  • Wait for all the release PRs to be merged
  • Create a new release using the draft release as a base, by clicking the Edit icon in the draft release
  • 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
  • Replace the prepopulated draft changelog in the release description with the final changelog you created; 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"
  • Delete all the draft releases from the list of releases

Test the Pre-Release

Publish Release

Publish Crates

  • Run cargo login
  • Run cargo clean in the zebra repo (optional)
  • Publish the crates to crates.io: cargo release publish --verbose --workspace --execute
  • Check that Zebra can be installed from crates.io: cargo install --locked --force --version 1.0.0 zebrad && ~/.cargo/bin/zebrad and put the output in a comment on the PR.

Publish Docker Images

Release Failures

If building or running fails after tagging:

  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