This document describes the current release process. It may or may not change in the future.
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):
Unreleasedto contain the version number and date for the release you are building. Create a pull request with the change.
Tag the release commit with the version number as soon as the PR is merged:
git tag v0.12.3, then
git push --tags
Build the release with
./dev/build.sh, then publish it with
Create an entry in GitHub releases with the release notes for the previously tagged commit and attach the build artifacts (
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