Release checklist
Forest doesn't follow a fixed schedule but releases should be expected at least quarterly. A release officer is volunteered for each release, and they are responsible for either following the checklist or, in case of absence, passing the task to a different team member.
Prepare the release
Make a pull request with the following changes:
- Update the CHANGELOG.md file to reflect all changes and preferably write a
small summary about the most notable updates. The changelog should follow the
design philosophy outlined here. Go through the output of
git log <last-tag>..HEADand remember that the audience of the CHANGELOG does not have intimate knowledge of the Forest code-base. All the changed/updated/removed features should be reasonably understandable to an end-user. - Update the version of the forest crate (and any others, if applicable) to
be released. Make sure that the updated files do not contain a
[patch.crates-io]section, otherwise you won't be able to make a release on crates.io. - Make sure to run
cargo publish --dry-runand include theCargo.lockcrate version change in the release. - The Pull Request must have the
Releaselabel.
Release on GitHub
- Create a new release. Click on
Choose a tagbutton and create a new one. The tag must start with a lowercasev, e.g.,v0.11.0. Follow the title convention of the previous releases, and write a small summary of the release (similar or identical to the summary in the CHANGELOG.md file). Add additional, detailed notes withGenerate release notesbutton. - Verify that the new release contains assets for both Linux and macOS (the assets are automatically generated and should show up after 30 minutes to an hour).
- 🔁 If it's a new stable release (and not a backport), tag the version as
latestwith the retag action. - Verify that the new release is available in the GitHub Container Registry. Use
docker pull ghcr.io/chainsafe/forest:<version>. Verify the tags in the packages list. - Verify that the new release is published to crates.io.