2.7 KiB
Release instructions
This document outlines the dbft release process. It can be used as a todo list for a new release.
Check the state
These should run successfully:
- build
- unit-tests
- lint
- simulation with default settings
Update CHANGELOG and ROADMAP
Add an entry to the CHANGELOG.md following the style established there. Add a codename, version and release date in the heading. Write a paragraph describing the most significant changes done in this release. In case if the dBFT configuration was changed, some API was marked as deprecated, any experimental changes were made in the user-facing code and the users' feedback is needed or if there's any other information that requires user's response, write another separate paragraph for those who uses dbft package. Then, add sections with release content describing each change in detail and with a reference to GitHub issues and/or PRs. Minor issues that doesn't affect the package end-user may be grouped under a single label.
- "New features" section should include new abilities that were added to the dBFT/API, are directly visible or available to the user and are large enough to be treated as a feature. Do not include minor user-facing improvements and changes that don't affect the user-facing functionality even if they are new.
- "Behaviour changes" section should include any incompatible changes in default settings or in API that are available to the user. Add a note about changes user needs to make if he uses the affected code.
- "Improvements" section should include user-facing changes that are too insignificant to be treated as a feature and are not directly visible to the package end-user, such as performance optimizations, refactoring and internal API changes.
- "Bugs fixed" section should include a set of bugs fixed since the previous release with optional bug cause or consequences description.
Create a PR with CHANGELOG changes, review/merge it.
Create a GitHub release and a tag
Use "Draft a new release" button in the "Releases" section. Create a new
vX.Y.Z tag for it following the semantic versioning standard. Put change log
for this release into the description. Do not attach any binaries.
Set the "Set as the latest release" checkbox if this is the latest stable
release or "Set as a pre-release" if this is an unstable pre-release.
Press the "Publish release" button.
Close GitHub milestone
Close corresponding X.Y.Z GitHub milestone.
Announcements
Copy the GitHub release page link to:
- Element channel
Dependant projects update
Create an issue or PR to fetch the updated package version in the dependant repositories.