-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Release v1.3.0 #7610
chore: Release v1.3.0 #7610
Conversation
Here's the list of excluded changes: Fix typo (#7516) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the fixes!
Edit: I let |
40cfd6a
to
1667987
Compare
This PR is ready for another review. |
Co-authored-by: teor <[email protected]>
Set the release height to start on ~ Monday, 2023-10-16.
Here's a list of new PRs that I included in the changelog:
|
Here's a list of new PRs that I didn't include in the changelog: imp(workflows): use larger runners on time consuming jobs #7626 |
I took out this entry from the changelog: Check database format is valid on shutdown in CI (#7606). We expect to catch almost all of these errors in CI (#7602, #7627). @teor2345 should I also take out the following one? Fix database concurrency bugs that could have led to panics or incorrect history tree data (#7590, #7663) |
This PR is ready for another round of reviews. |
I think I made an incorrect suggestion here. The startup and shutdown checks are run in production and visible to users. So that changelog entry should have said: Check database format is valid on shutdown (#7606) This part is optional because it is CI only, but it might be useful for users to know: We expect to catch almost all database validity errors in CI (#7602, #7627), so users are unlikely to see them on startup or shutdown.
These panics or incorrect data are visible to users (if they happen in production). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rest looks good, thanks!
Co-authored-by: teor <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Here's the output from
|
name: 'Release Checklist Template'
about: 'Checklist to create and publish a Zebra release'
title: 'Release Zebra (version)'
labels: 'A-release, C-trivial, P-Critical 🚑'
assignees: ''
Prepare for the Release
(See the release ticket checklist for details)
Summarise Release Changes
These steps can be done a few days before the release, in the same PR:
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:
CHANGELOG.md
(there can be multiple draft releases)README
README updates can be skipped for urgent releases.
Update the README to:
Check for changes in the
Dockerfile
since the last tag:git diff <previous-release-tag> docker/Dockerfile
.Cargo.toml
sYou can use a command like:
Create the Release PR
for example:
bump-v1.0.0
- this needs to be different to the tag name&template=release-checklist.md
to the comparing url (Example).batched
queue using Mergify.Critical
priority, so they go in theurgent
Mergify queue.do-not-merge
, because Mergify checks approved PRs against every commit, even when a queue is frozen.Update Versions and End of Support
Update Zebra Version
Choose a Release Level
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:major
releasesminor
releasespatch
releaseZebra's Rust API doesn't have any support or stability guarantees, so we keep all the
zebra-*
andtower-*
crates on a betapre-release
version.Update Crate Versions
If you're publishing crates for the first time, log in to crates.io,
and make sure you're a member of owners group.
Check that the release will work:
Crate publishing is automatically checked in CI using "dry run" mode.
Update End of Support
The end of support height is calculated from the current blockchain height:
ESTIMATED_RELEASE_HEIGHT
inend_of_support.rs
with the height you estimate the release will be tagged.Optional: calculate the release tagging height
1152
blocks for each day until the release1152 * 3
to the current Mainnet block heightUpdate the Release PR
Publish the Zebra Release
Create the GitHub Pre-Release
for example:
v1.0.0
main
branchZebra
followed by the version tag,for example:
Zebra 1.0.0
starting just after the title
## [Zebra ...
of the current version being released,and ending just before the title of the previous release.
Test the Pre-Release
main
, and the quick tests have passed.Publish Release
Publish Crates
cargo login
cargo clean
in the zebra repo (optional)cargo release publish --verbose --workspace --execute
crates.io
:cargo install --locked --force --version 1.minor.patch zebrad && ~/.cargo/bin/zebrad
and put the output in a comment on the PR.
Publish Docker Images
batched
queue using Mergify.do-not-merge
from the PRs you added it toRelease Failures
If building or running fails after tagging:
Tag a new release, following these instructions...
patch
releaseCHANGELOG.md
with details about the fix