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

  1. Run python3 ./dev/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).

  2. 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 pyproject.toml (notice the v added before it). This will replace the Unreleased 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.

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

  4. 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. Augmente la version mineure de pyproject.toml d’une unité.

  2. Mets à jour tous les fichiers qui contiennent le numéro de version actuel si nécessaire.

  3. Ajoute une nouvelle section Unreleased dans changelog.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