Que veulent dire les chiffres dans les versions ?
Une dépendance passe de 1.2.2 à 2.0.0. Le premier chiffre annonce un changement qui peut demander d’adapter votre code. Comment lire ces numéros ?
Lire MAJOR.MINOR.PATCH
Dans une version comme 1.2.2, chaque nombre a un rôle si le projet suit la gestion sémantique de version, ou SemVer. Cette convention décrit les changements de son API publique : les fonctions et les comportements documentés sur lesquels le code utilisateur peut s’appuyer.
- MAJOR augmente quand l’API publique change de façon incompatible. Par exemple, supprimer une fonction utilisée par votre application vous oblige à modifier le code qui l’appelle.
- MINOR augmente quand une fonctionnalité est ajoutée de façon rétrocompatible. Les usages existants continuent de fonctionner. Marquer une fonction publique comme obsolète demande aussi une version mineure.
- PATCH augmente pour des corrections de bugs rétrocompatibles. Le correctif répare un comportement incorrect en préservant la compatibilité de l’API publique.
Quel numéro augmenter en pratique ?
Voici des exemples de changements et de leurs numéros de version :
1.0.0 → correction de bug compatible → 1.0.1
1.0.1 → nouvelle fonctionnalité compatible → 1.1.0
1.2.2 → changement incompatible → 2.0.0Quand MINOR augmente, PATCH revient à zéro. Quand MAJOR augmente, MINOR et PATCH reviennent à zéro. Une version majeure peut aussi contenir des corrections ; la présence d’un changement incompatible suffit à imposer ce niveau.
De 0.1.0 à 1.0.0
Démarrer à 0.1.0 convient au développement initial. Tant que la version reste en 0.y.z, SemVer considère que l’API publique peut encore changer à tout moment. Un passage de 0.2.0 à 0.3.0 peut donc demander une adaptation du code utilisateur.
Le passage à 1.0.0 marque la définition d’une API publique stable, avec un engagement sur la façon de signaler ses évolutions. Le produit peut encore avoir des bugs. La stabilité désigne ici le contrat sur lequel les utilisateurs peuvent construire leur propre code.
Alpha, bêta et release candidate
Un suffixe après un trait d’union signale une préversion : 1.0.0-alpha, 1.0.0-beta ou 1.0.0-rc.1. Elle précède la version finale correspondante et peut encore être instable. Ces versions demandent une évaluation en environnement de test avant d’envisager leur usage en production.
1.0.0-alpha < 1.0.0-beta < 1.0.0-rc.1 < 1.0.0Ce que signifie le signe +
Dans 1.0.0+20130313144700, la partie après le signe + contient des métadonnées de build. On peut y inscrire un identifiant permettant de retrouver la compilation correspondante. Ces métadonnées sont ignorées dans l’ordre des versions : 1.0.0+build.1 et 1.0.0+build.2 ont la même priorité.
Avant de mettre à jour une dépendance
Ces repères supposent que le projet respecte SemVer. Un PATCH annonce une correction compatible, mais une régression reste possible. Avant de valider la mise à jour, consultez les notes de version et vérifiez les parcours qui utilisent la dépendance. Si MAJOR change, cherchez aussi les consignes de migration. Cela laisse le temps d’adapter le code avant de découvrir le problème en production un vendredi soir.
