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 release est indiqué dans ./framework/pyproject.toml. Pour lancer une nouvelle version de Flower, les choses suivantes doivent se produire (dans cet ordre):

  1. Exécutez python3 ./framework/dev/update_changelog.py <YOUR_GH_TOKEN> pour ajouter tous les nouveaux changements au journal de changelog. Vous pouvez faire des édits manuels au journal de changelog après coup pour améliorer sa mise en forme ou son vocabulaire. Ce script remplacera également l’en-tête ## Unreleased par le nouveau numéro de version et la date actuelle, et ajoutera un message de remerciement pour les contributeurs. Ouvrez une demande de tirage avec ces changements.

  2. Une fois que la demande de tirage est fusionnée, marquez le commit de version avec le numéro de version : git tag v<NEW_VERSION> (prenez note du v ajouté avant le numéro de version), puis git push --tags. Cela créera une mise en ligne de brouillon sur GitHub contenant les artefacts corrects et la partie pertinente du changelog.

  3. Vérifiez la mise en ligne préliminaire sur GitHub, et si tout est bien, publiez-la.

Après la publication

Crée une demande de pull qui contient les modifications suivantes :

  1. Augmentez la sous-version dans pyproject.toml d’une unité et mettez à jour tous les fichiers qui contiennent le numéro de version actuel (si nécessaire) en exécutant ./framework/dev/update_version.py.

  2. Ajoutez une nouvelle section ## Unreleased au début de ./framework/docs/source/ref-changelog.md pour se préparer à des futurs changements.

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