This document describes the current release process. It may or may not change in the future.
During the release#
The version number of a release is stated in
pyproject.toml. To release a new version of Flower, the following things need to happen (in that order):
python3 src/py/flwr_tool/update_changelog.py <YOUR_GH_TOKEN>in order to add every new change to the changelog (feel free to make manual changes to the changelog afterwards until it looks good).
Once the changelog has been updated with all the changes, run
./dev/prepare-release-changelog.sh v<NEW_VERSION>, where
<NEW_VERSION>is the version stated in
vadded before it). This will replace the
Unreleasedheader of the changelog by the version and current date, and it will add a thanking message for the contributors. Open a pull request with those changes.
Once the pull request is merged, tag the release commit with the version number as soon as the PR is merged:
git tag v<NEW_VERSION>(notice the
vadded before the version number), then
git push --tags. This will create a draft release on GitHub containing the correct artifacts and the relevant part of the changelog.
Check the draft release on GitHub, and if everything is good, publish it.
After the release#
Create a pull request which contains the following changes:
Increase the minor version in
Update all files which contain the current version number if necessary.
Add a new
Merge the pull request on the same day (i.e., before a new nighly release gets published to PyPI).
Publishing a pre-release#
PyPI supports pre-releases (alpha, beta, release candiate). Pre-releases MUST use one of the following naming patterns:
Release candiate (RC):
This is in line with PEP-440 and the recommendations from the Python Packaging Authority (PyPA):
Note that the approach defined by PyPA is not compatible with SemVer 2.0.0 spec, for details consult the Semantic Versioning Specification (specifically item 11 on precedence).
Should the next pre-release be called alpha, beta, or release candidate?
RC: feature complete, no known issues (apart from issues that are classified as “won’t fix” for the next stable release) - if no issues surface this will become the next stable release
Beta: feature complete, allowed to have known issues
Alpha: not feature complete, allowed to have known issues