Publier Flower¶
Ce document décrit le processus de diffusion actuel, qui peut ou non changer à l’avenir.
Lors de la sortie¶
The version number of a release is stated in ./framework/pyproject.toml
. To release
a new version of Flower, the following things need to happen (in that order):
Run
python3 ./framework/dev/update_changelog.py <YOUR_GH_TOKEN>
to add all new changes to the changelog. You can make manual edits to the changelog afterward to improve its formatting or wording. This script will also replace the## Unreleased
header with the new version number and current date, and add a thank-you message for contributors. Open a pull request with these changes.Once the pull request is merged, tag the release commit with the version number:
git tag v<NEW_VERSION>
(notice thev
added before the version number), thengit 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.
Après la publication¶
Crée une demande de pull qui contient les modifications suivantes :
Increase the minor version in
pyproject.toml
by one and update all files which contain the current version number (if necessary) by running./framework/dev/update_version.py
.Add a new
## Unreleased
section at the top of./framework/docs/source/ref-changelog.md
to prepare for future changes.
Fusionne la pull request le jour même (c’est-à-dire avant qu’une nouvelle version nightly ne soit publiée sur PyPI).
Publier une pré-version¶
Nom de la pré-version¶
PyPI prend en charge les préversions (alpha, bêta, version candidate). Les préversions DOIVENT utiliser l’un des modèles de dénomination suivants :
Alpha :
MAJOR.MINOR.PATCHaN
Bêta :
MAJOR.MINOR.PATCHbN
Candidat à la publication (RC) :
MAJOR.MINOR.PATCHrcN
Voici quelques exemples :
1.0.0a0
1.0.0b0
1.0.0rc0
1.0.0rc1
Ceci est conforme au PEP-440 et aux recommandations de l’Autorité de l’emballage Python (PyPA) :
Note que l’approche définie par PyPA n’est pas compatible avec la spécification SemVer 2.0.0, pour plus de détails, consulte la Semantic Versioning Specification (en particulier le point 11 sur la préséance).
Classification avant publication¶
La prochaine préversion doit-elle être appelée alpha, bêta ou release candidate ?
RC : fonctionnalités complètes, pas de problèmes connus (à l’exception des problèmes classés comme « à ne pas corriger » pour la prochaine version stable) - si aucun problème n’apparaît, cette version deviendra la prochaine version stable
Bêta : fonctionnalité complète, autorisée à avoir des problèmes connus
Alpha : les fonctionnalités ne sont pas complètes, les problèmes connus sont autorisés