Sujet : release-management
-
Tags et releases : tags légers versus tags annotés, et comment ils se propagent
Un tag léger n'est qu'un nom pour un commit ; un tag annoté est un objet portant l'auteur du tag, une date, un message et une signature optionnelle, ce pourquoi git describe ignore par défaut les tags légers et pourquoi les releases devraient utiliser des tags annotés ou signés ; les tags ne sont pas poussés avec les branches à moins d'utiliser --follow-tags ou --tags, et un tag publié ne devrait jamais être déplacé.
-
Le cherry-pick : quand il convient et ce qu'il coûte à l'historique
git cherry-pick rejoue la modification d'un commit sous la forme d'un nouveau commit avec un identifiant différent ; c'est l'outil approprié pour rétroporter un correctif vers une branche de maintenance ou récupérer un commit isolé d'une branche abandonnée, mais chaque cherry-pick crée un doublon que les fusions ne peuvent pas reconnaître, d'où l'intérêt d'enregistrer l'origine avec -x et de fusionner plutôt que de cherry-picker lorsque c'est la branche entière qui est voulue.
-
Cadence de publication pour un petit projet : trains à intervalle fixe contre publication à la demande
Un numéro de version indique ce qu'une publication promet ; une politique de cadence indique quand les publications ont lieu. Rust publie une version stable toutes les six semaines depuis un train nightly, beta, stable ; Python est passé à une publication annuelle de fonctionnalités avec la PEP 602 ; et Django publie ses versions de fonctionnalités selon un calendrier fixe, avec des correctifs publiés au besoin. Un petit projet peut reprendre cette structure : des publications de fonctionnalités sur un calendrier ou quand quelque chose de notable s'est accumulé, des correctifs dès qu'une réparation est prête.
-
Déprécier une fonction dans une bibliothèque : avertir, documenter le remplacement, supprimer selon un calendrier
Une dépréciation dans une bibliothèque comporte quatre volets : un remplacement qui existe d'abord, un avertissement à l'exécution complété d'une note de documentation nommant la version et le remplacement, une entrée dans le journal des modifications, et une version de suppression fixée à l'avance par une politique. La PEP 387 exige une période de dépréciation d'au moins deux ans sous la cadence annuelle de Python, et décrit une dépréciation douce, purement documentaire ; Django ne retire les rustines de compatibilité (shims) au plus tôt que deux versions fonctionnelles après l'avertissement.
-
Conventional Commits : des types de commit lisibles par une machine
La spécification Conventional Commits ajoute aux messages de commit un préfixe typé (feat, fix, et d'autres) ainsi que des marqueurs de changement incompatible, afin que les journaux de changements et les incréments de version puissent être dérivés automatiquement.
-
Semantic Versioning : ce que promet un numéro de version
Semantic Versioning 2.0.0 encode des promesses de compatibilité dans MAJOR.MINOR.PATCH et définit des suffixes de pré-version et de métadonnées de build ; cela ne fonctionne que si l'API publique est déclarée.
-
Versionnage d'API : quand et comment rompre la compatibilité
La plupart des changements peuvent être additifs ; une nouvelle version majeure est un dernier recours qui double la surface à maintenir. Versionner dans le chemin ou le type de média, documenter les règles de compatibilité, et déprécier avant de supprimer.
-
Supporting several release lines: which fixes go where
A support policy is a table of release lines with a status each (feature, bugfix, security-only, end of life) and a rule for which fix classes are backported to which lines. Python maintains a series with bugfix releases for two years and security-only releases for three more; Django backports critical fixes to the last feature release and security and data-loss fixes to the last two plus long-term-support lines; Rust supports only the most recent stable. A small project should publish the table and default to the narrowest promise it can keep.
-
Keeping a changelog for humans
A changelog is a curated, chronologically ordered list of notable changes per version; Keep a Changelog defines a small structure (Added, Changed, Deprecated, Removed, Fixed, Security) and an Unreleased section.
Lisible par machine : JSON