Cadence de publication pour un petit projet : trains à intervalle fixe contre publication à la demande

Ce que c'est

Deux familles de cadence existent. À intervalle fixe : une publication sort à une date donnée, indépendamment de ce qui est terminé. Le livre Rust décrit un modèle de train où, toutes les six semaines, une beta se ramifie depuis la version nightly et, six semaines plus tard, devient stable ; la PEP 602 a fait passer Python à un cycle de publication annuel, avec des versions de fonctionnalités chaque octobre ; le processus de publication de Django indique que les versions de fonctionnalités suivent un calendrier fixe, tandis que les correctifs sont publiés au besoin. Fondée sur les fonctionnalités : une publication a lieu lorsqu'un ensemble prévu de changements est complet. Le versionnage (Semantic Versioning, en lien) régit ce que le numéro promet ; la cadence régit le moment où un numéro apparaît.

Pourquoi c'est important

Le livre Rust donne l'argument en faveur des trains : si une fonctionnalité manque une publication, la suivante est proche, ce qui réduit la pression à intégrer du travail non abouti avant une échéance. Pour un projet avec une ou deux personnes responsables de la maintenance, c'est l'échec inverse qu'il faut surveiller : les publications deviennent rares parce que chacune ressemble à un événement, si bien que des correctifs restent non publiés sur la branche principale pendant des mois et que des utilisateurs font tourner des forks corrigés.

Comment l'appliquer

• Séparer les deux types de publication. Les correctifs sortent dès qu'une réparation est prête et que l'intégration continue est au vert ; les versions de fonctionnalités sortent selon un rythme annoncé ou lorsqu'un changement notable s'est accumulé, selon ce que le projet peut tenir.
• Écrire la politique là où le lectorat la cherche (README ou documentation) : ce qui déclenche une publication, quelles lignes sont maintenues, et où se trouve le journal des modifications.
• Faire en sorte qu'une publication coûte des minutes : un tag, une section de journal des modifications générée, une publication scriptée. Une cadence qui dépend d'une checklist manuelle finit par être sautée.
• Déclarer une règle de gel pour les versions de fonctionnalités : après la coupure, seuls les correctifs entrent dans la branche de publication, comme pendant la période beta de Rust.
• Annoncer via le journal des modifications, pas via le tag ; le lectorat veut savoir ce qui a changé et si la mise à niveau est sûre.

Pièges

Faire progresser un numéro de version majeure pour un effet marketing plutôt que pour signaler une incompatibilité. Des trains à intervalle fixe sans tests automatisés se transforment en régressions programmées. Publier un gros lot après une longue pause rend une bissection de régression coûteuse pour les utilisateurs. Laisser « on publie quand c'est prêt » devenir « on n'a rien publié cette année ».