Mise en place des releases

Mise en place d'un protocole de release

LA version 1.0.1-gigi est sorties et déjà la version 1.1.1-gigi apportant correctifs + évolution est déjà là. Il est temps de se pencher sur la manière de gérer les différentes releases qu'elles soient programmées ou simplement correctives

Numérotation sémantique des versions logicielles (X.Y.Z)

Le principe de la numérotation des versions logicielles au format X.Y.Z repose sur le versionnage sémantique, où chaque chiffre séparé par un point a un rôle précis :

• X (version majeure)
  ➔ Augmente lors de changements importants, généralement non rétrocompatibles (évolution majeure, rupture d’API). Exemple : de 1.4.2 à 2.0.0

• Y (version mineure)
  ➔ Incrémentée lors de l’ajout de fonctionnalités ou changements rétrocompatibles. Exemple : de 1.4.2 à 1.5.0

• Z (correctif / patch)
  ➔ Augmente pour chaque correction de bug ou ajustement mineur et compatible. Exemple : de 1.5.0 à 1.5.1

Règles générales

• Changement majeur (cassure de compatibilité) : augmente X, remet Y et Z à zéro.
• Ajout rétrocompatible : augmente Y, remet Z à zéro.
• Correction mineure : augmente Z.

Exemples

• 1.3.1 : première version majeure, troisième mise à jour mineure, premier correctif.
• 2.0.0 : nouvelle version majeure, souvent une refonte ou une rupture de compatibilité.

Résumé visuel

Format	Rôle
X	Majeur (rupture/évolution forte)
Y	Mineur (nouvelles fonctionnalités)
Z	Correctif (bugs, petites corrections)

Ce système s’appelle versionnage sémantique (SemVer) et est un standard pour communiquer clairement sur la nature des changements d’un logiciel.

Notes de release

Pour chaque release il convient de noter quelque part les modifications apportées par cette release.

Je proposerais donc d'ajouter dans la documentation une section version avec l'enumération des différentes releases pointant chacune vers une page de description.

En attendant on pourra aussi utiliser le commentaire du tag quand on créé la release.

déploiement

• dev -> vérifier grossièrement et pour chaque modifications que les tests passent, et que le déploiement, l'affichage ... est OK
• preprod -> avant de taguer faire les tests de portage, et pour chaque application une revue approfondie, passer les ticket de OA à Completed. TAguer si necessaire ces tickete avec le numéro de la release
• prêt pour taguer -> vérifier le contenu des notes de release
• déploiement sur les serveurs de cette release 'normalement de manière transparente) On peut si on le veut prendre les bases de préprod pour ce déploiement.

Préparation des releases.

une revue des tickets doit permettre de déterminer le contnu d'une release non corrective. Ne pa s être trop gourmand et préférer des sauts rapides que des grands "runs"

Parfois des correctifs peuvent amener à des modifications non prévues. Cela doit rester exceptionnels

En dehors des évolutions prévues dans la release, il faut préparer les spécifications de fonctionalités et dédiant des groupes "intéressés" qui font un travail préparatoire avant de le présenter à l'ensemble des acteurs. Ces spécifications devront être complètes pour être intégrées dans une release.

Normalemnt une fois intégrée dans une release toute modification des specs devra faire l'objet d'une autre release.