🎯 Intention

Le “Semantic Versionning” consiste à utiliser une convention de nommage pour les numéros de version.

Cette pratique est souvent liée au Continuous Delivery, car le but est donner des informations importantes à chaque release/déploiement à la personne qui va utiliser le produit.

On va rechercher à automatiser au maximum ce process afin de réduire l’effort de la mise en production.

<aside> ✅ Pré-requis

Tous les commits du repository git doivent suivre Git : Ecrire un message de commit clair, concis et utile
Gitmoji est nécessaire (pour générer un historique sémantique) </aside>

✅ Point clés

Points Clés	Raison
🏷 Spec SemVer
Exemple: 1.0.2-beta.0+meta	Le standard de l’industrie par défaut. La spec est disponible sur semver.org . Ceci permet à l’utilisateur le l’app/library de connaitre le type d’évolution qu’il va recevoir lors de la mise à jour.
🤖 Un script de `release` génère la version à partir de l’historique git+gitmoji
*Exemple 1 : 🔥 x1 ⇒ version majeur,
Exemple 2 : 🔥 x0, ✨ x1 ⇒ version mineur*
****	On souhaite que la génération du numéro de version soit rapide et sans erreur humaine.

❌ Erreurs types à éviter

⚠️ App Mobile : AppStore et PlayStore ne supportent que le format X.X.X, il faut donc pas utiliser de suffixe (ex: -beta.1)
Avoir “peur” de créer des numéro de version élevés (10.x, 100.x), n’est pas un problème même si cela est peu commun.
Oublier d’augmenter la version majeure d’une library après un breaking change. Cela peut avoir de lourdes conséquences pour les projets qui l’utilisent.
Oublier de changer la version major lorsque l’on supprime le support d’un version de NodeJS, Ruby, etc

🎯 Intention

✅ Point clés

❌ Erreurs types à éviter

🎓 Aller plus loin

Spec de Semantic Versioning (Documentation originale)