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):

  1. 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.

  2. Once the pull request is merged, tag the release commit with the version number: git tag v<NEW_VERSION> (notice the v added 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.

  3. 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 :

  1. 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.

  2. 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