Comment ça se passe la sortie d’une nouvelle version de SPIP ?

1^re étape : faire le tour des pull-request en attente

Pour que les modifications en cours soient prises en compte dans la nouvelle version, elles doivent être fusionnées, il faut donc en faire le tour une par une. S’il y a consensus sur une pull-request, elle est fusionnée (merge), sinon, elle reste « en cours de développement » (WIP / « work in progress »).

Avant de fusionner, il faut régulièrement corriger le changelog (formulation, accents...) voir même le créer si ça n’a pas été fait, ce qui demande du temps supplémentaire à cette étape.

2^e étape : préparer les fichiers

Le principe est de récupérer localement, depuis la forge communautaire, les dépôts SPIP et plugin-dist avec checkout, puis de générer un aperçu des modifications depuis la dernière version publiée (changelog + les commits).

Pour le core : mise à jour des fichiers CHANGELOG.md et paquet.xml ainsi que plugins-dist.json et ecrire/inc-version.php puis création des tags localement avant de pousser sur le dépot distant.
Pour plugins-dist : mise à jour des CHANGELOG.md et paquet.xml puis création des tags localement avant de pousser sur les dépôts distants.

Cette étape est réalisée avec le script spip-releases

3^e étape : faire le zip

Cette étape permet de générer l’archive contenant tous les fichiers : c’est le fichier zip qu’on télécharge pour installer SPIP.

Cette étape est réalisée avec le script spip-archives

4^e étape : distribuer

Mise à jour du fichier release.json pour diffuser le zip généré à l’étape précédente sur les page téléchargement et versions maintenues de spip.net, script spip_loader.php, pied de page espace privé... etc.

Cette étape est réalisée avec le plugin supported-versions

5^e étape : communication

Préparation et publication de l’article pour annoncer la nouvelle version sur discuter et sur le blog (qui est automatiquement partagé sur Mastodon).

Ca y est, la nouvelle version de SPIP est sortie, vous n’avez plus qu’à faire la mise à jour via la méthode de votre choix.

Alors, vous êtes à jour ?
– https://blog.spip.net/-Release-.html

Pourquoi faire une release tous les mois ?

Publier régulièrement des versions de maintenance, en plus de distribuer les corrections de bugs plus rapidement, permet également de limiter le nombre de modifications entre 2 versions.

Ça a plusieurs intérêts :

• moins de pull-request à réviser d’un coup
• moins de modifications publiées en même temps donc moins de problèmes potentiels
• si problème, il y a moins de commits à vérifier donc la résolution est beaucoup plus facile que s’il y avait 6 mois de commits
• il y a moins de problèmes donc c’est plus rassurant pour les utilisateur·rices qui mettront à jour plus facilement et plus régulièrement (y compris les mises à jour de sécurité)
• il n’est pas nécessaire de fermer un maximum de tickets dans un temps court (marathon des tickets) car il y aura une nouvelle version le mois suivant

Conclusion

C’est fastidieux car tout ça demande beaucoup d’interventions manuelles malgré les différents scripts qui automatisent certaines étapes : à 2 personnes, il faut minimum 1h30 quand ça se passe bien voir beaucoup plus quand il y a plus de choses à revoir. Par exemple, la sortie de version 4.2.7 (18 décembre 23) a nécessité 8h à b_b et marcimat, ça demande donc de la disponibilité.

Dans l’écosystème PHP, grace à Composer et aux outils de CI / CD (Continuous Integration, Continuous Deployment), c’est la création du tag qui fait automatiquement toutes ces étapes, ce qui permet d’économiser du temps et de l’énergie.

Aussi, une grosse part du travail concerne la lecture et la validation des pull-requests pour intégrer les nouvelles fonctionnalités et corrections de bugs : il faudrait plus de monde pour faire ce travail au fil de l’eau et non au moment de la release.

Voir la check-list suivie pour une release

Merci à marcimat et b_b pour leur temps et disponibilité.