Versionnement Sémantique (SemVer)

Vous avez vu des numéros de version partout : 1.0.0, 2.4.1, 4.0.0-beta.2. Mais que signifient-ils vraiment ? Comment savoir si la mise à jour d'une dépendance de 2.1.5 à 3.0.0 va casser toute votre application ?

Le Versionnement Sémantique (SemVer) est la réponse. C'est un standard universel qui raconte une histoire claire sur le type de changements contenus dans une nouvelle version.

Le Cœur : MAJEUR.MINEUR.PATCH

Un numéro SemVer est divisé en trois parties principales. Une fois que vous les comprenez, vous pouvez évaluer l'impact de n'importe quel changement de version d'un seul coup d'œil.

💥 Version MAJEURE

La Règle : Vous incrémentez la version MAJEURE lorsque vous introduisez des changements cassants et incompatibles avec l'API.

Quand l'utiliser : Une fonction a été supprimée, un endpoint a changé sa réponse, ou tout ce qui forcerait les utilisateurs de votre code à changer le leur.

Exemple : Passer de 1.5.2 à 2.0.0 est un signal de danger. Mettez à jour avec prudence !

✨ Version MINEURE

La Règle : Vous incrémentez la version MINEURE lorsque vous ajoutez de nouvelles fonctionnalités de manière rétrocompatible.

Quand l'utiliser : Vous avez ajouté une nouvelle fonctionnalité, un nouveau paramètre optionnel, ou un nouveau endpoint sans altérer les existants.

Exemple : Passer de 2.0.0 à 2.1.0 ajoute des nouveautés sans casser l'ancien.

🐛 Version PATCH

La Règle : Vous incrémentez la version PATCH lorsque vous appliquez des correctifs de bugs de manière rétrocompatible.

Quand l'utiliser : Vous avez corrigé quelque chose qui ne fonctionnait pas mais sans changer de fonctionnalité. C'est courant pour les hotfixes.

Exemple : Passer de 2.1.0 à 2.1.1 est une correction de bug sûre et recommandée.

La Phase de "Développement Initial"

Avant votre première version officielle, votre version MAJEURE doit être 0. La version 0.y.z indique que le projet est à ses débuts et que tout peut changer à tout moment. Nous commençons avec 1.0.0 une fois que l'application est déployée en production pour la première fois.

Anatomie de Notre Version Complète

Les numéros MAJEUR.MINEUR.PATCH ne sont que le cœur. Une chaîne de version complète nous donne encore plus de détails.

Notre chaîne de version complète a trois parties :

1. Version Cœur: MAJEUR.MINEUR.PATCH comme décrit ci-dessus.
2. Tag de Pré-release: Une étiquette qui qualifie la stabilité du build. Dans notre workflow, ce tag est déterminé par la branche :
   • nom-de-branche: Indique un build en développement depuis une branche de feature ou de bugfix. Très instable.
   • -beta: Un build depuis la branche main. Toutes les fonctionnalités sont terminées, mais il n'est pas encore validé pour la production.
   • -rc (Release Candidate): Un build depuis une branche support/*. C'est un candidat pour une mise en production, en cours de vérification finale.
   • (pas de tag): Une version de production complète, taguée et déployée.
3. Numéro de Build: Un nombre qui s'incrémente à chaque build ou commit, assurant l'unicité.

Ainsi, une version comme 1.1.0-beta.1 signifie : "Ceci est le premier build d'une version beta pour la version 1.1.0."

La Magie : Comment les Versions sont Incrémentées Automatiquement

Comment obtenir le bon numéro de version à chaque fois ? Nous combinons les deux concepts précédents :

Conventional Commits + Nom de Branche Git = Le Bon Numéro SemVer

(GitVersion) calcule automatiquement la prochaine version en analysant vos messages de commit et la branche sur laquelle vous êtes.

• Un commit fix: incrémentera la version PATCH.
• Un commit feat: incrémentera la version MINEURE.
• Un commit avec BREAKING CHANGE: incrémentera la version MAJEURE.

Scénario d'Exemple

Voyons cela en action. La dernière version en production était taguée 1.0.0.

1. Un développeur merge une correction de bug : fix(JIRA-2): ma correction.
   • La version sur main devient 1.0.1-beta.1. (Incrémentation Patch, premier build beta)
2. Un autre développeur merge une seconde correction : fix(JIRA-3): ma deuxième correction.
   • La version sur main devient 1.0.1-beta.2. (Le numéro de build augmente)
3. Une nouvelle fonctionnalité est mergée : feat(JIRA-4): ma fonctionnalité.
   • La version sur main devient 1.1.0-beta.3. (L'incrémentation Mineure l'emporte sur le patch, le numéro de build continue)
4. Une autre nouvelle fonctionnalité est mergée : feat(JIRA-5): ma fonctionnalité.
   • La version sur main devient 1.1.0-beta.4. (Le numéro de build augmente)
5. Finalement, un breaking change est mergé : refactor(JIRA-6)!: nouveau système d'auth.
   • La version sur main devient 2.0.0-beta.5. (L'incrémentation Majeure l'emporte sur tout, le numéro de build continue)

Ce système garantit que nos numéros de version sont toujours prévisibles, significatifs et générés sans aucun travail manuel.

Pour tous les détails, visitez la spécification officielle de Semantic Versioning.