Revise release checklist to be more explicit
This commit is contained in:
parent
b8742f03a9
commit
c8b8a428c6
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue