Publier Flower#
Ce document décrit le processus de diffusion actuel, qui peut ou non changer à l’avenir.
Lors de la sortie#
Le numéro de version d’une version est indiqué dans pyproject.toml
. Pour publier une nouvelle version de Flower, les choses suivantes doivent se produire (dans cet ordre) :
Run
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 inpyproject.toml
(notice thev
added before it). This will replace theUnreleased
header 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 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 :
Augmente la version mineure de
pyproject.toml
d’une unité.Mets à jour tous les fichiers qui contiennent le numéro de version actuel si nécessaire.
Ajoute une nouvelle section
Unreleased
danschangelog.md
.
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