diff --git a/.github/PULL_REQUEST_TEMPLATE/release-checklist.md b/.github/PULL_REQUEST_TEMPLATE/release-checklist.md index f2aa30c4..d6c2f39c 100644 --- a/.github/PULL_REQUEST_TEMPLATE/release-checklist.md +++ b/.github/PULL_REQUEST_TEMPLATE/release-checklist.md @@ -26,36 +26,34 @@ To check if any of the top-level crates need version increments, go to the zebra Zebra follows [semantic versioning](https://semver.org). -Semantic versions look like: -`MAJOR`.`MINOR`.`PATCH[`-`TAG`.`PRE-RELEASE]` +Semantic versions look like: `MAJOR`.`MINOR`.`PATCH[`-`TAG`.`PRE-RELEASE]` #### Pre-Release Crates -Pre-Release versions have a `TAG` like "alpha" or "beta". -For example: "1.0.0-alpha.0" +Pre-Release versions have a `TAG` like "alpha" or "beta". For example: `1.0.0-alpha.0` 1. Increment the `PRE-RELEASE` version for the crate. Optionally, if a `MINOR` feature pre-release breaks `MAJOR` API compatibility: + 2. Increment the `MAJOR` version, and reset all the other versions to zero #### Unstable Crates -Unstable versions have a `MAJOR` version of zero. -For example: "0.1.0" +Unstable versions have a `MAJOR` version of zero. For example: `0.1.0` 1. Follow stable crate versioning, but increment the `MINOR` version for breaking changes #### Stable Crates -For example: "1.0.0" +For example: `1.0.0` Increment the first version component in this list, and reset the other components to zero: 1. MAJOR versions for breaking public API changes and removals - * check for types from dependencies that appear in the public API + * check for types from dependencies that appear in the public API 2. MINOR versions for new features 3. PATCH versions for bug fixes - * includes dependency updates that don't impact the public API + * includes dependency updates that don't impact the public API ### Version Locations @@ -65,6 +63,7 @@ Once you know which versions you want to increment, you can find them in the: - [ ] `zebrad` app code: https://github.com/ZcashFoundation/zebra/blob/main/zebrad/src/components/tracing/component.rs - [ ] `zebra-network` protocol user agent: https://github.com/ZcashFoundation/zebra/blob/main/zebra-network/src/constants.rs - [ ] `README.md` +- [ ] `Cargo.lock`: automatically generated by `cargo build` Merge all these version increments as one commit, by squashing and rebasing the PR onto the main branch. @@ -83,11 +82,14 @@ We skipped `tower-fallback`, because it hadn't changed since the last tag. ## Change Log +**Important**: Any merge into `main` deletes any edits to the draft changelog. Edit the draft changelog in a pad like https://pad.riseup.net + We follow the [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) format. We use [the Release Drafter workflow](https://github.com/marketplace/actions/release-drafter) to automatically create a [draft changelog](https://github.com/ZcashFoundation/zebra/releases). To create the final change log: +- [ ] Copy the draft changelog into a pad like https://pad.riseup.net - [ ] Delete any trivial changes - [ ] Combine duplicate changes - [ ] Edit change descriptions so they are consistent, and make sense to non-developers @@ -104,11 +106,12 @@ From "Keep a Changelog": * `Fixed` for any bug fixes. * `Security` in case of vulnerabilities. -**Important**: Any merge into `main` while the Changelog is still in draft state will remove all the changes made and create a new raw list. Save your Changelog changes locally while in draft to avoid having to redo the list if that happens. - ## After merging this PR +- [ ] Check for any PRs that have been merged since you created the changelog pad - [ ] Update the draft release with the final changelog -- [ ] Point the draft release at the commit resulting from merging this PR, using the correct version tag name +- [ ] Set the release title to `Zebra ` followed by the version tag, for example: `Zebra 1.0.0-alpha.0` +- [ ] Set the tag name to the version tag, for example: `1.0.0-alpha.0` +- [ ] Set the release to target the `main` branch - [ ] Mark the release as 'pre-release' (until we are no longer alpha/beta) ## Final Testing @@ -120,4 +123,4 @@ If the build fails after tagging: 1. fix the build 2. check if the fixes changed any extra crates, and do the required version increments 3. update `README.md` with a **new** git tag -4. tag **another** release +4. tag a **new** release