Dans cet article
Qu'est-ce que le versionnage semantique ?
Le versionnage sémantique (SemVer) est un schéma de versionnage qui attribue une signification à chaque partie d'un numéro de version. Créé par Tom Preston-Werner, SemVer fournit une convention universelle pour communiquer la nature et l'impact des changements logiciels uniquement par les numéros de version.
En suivant SemVer, les développeurs et les utilisateurs peuvent immédiatement comprendre si une mise à jour introduit des changements incompatibles, de nouvelles fonctionnalités ou des corrections de bugs — rien qu'en lisant le numéro de version. Cette prévisibilité est cruciale pour la gestion des dépendances dans les écosystèmes logiciels modernes.
Le format SemVer
Une version sémantique se compose de trois composantes numériques séparées par des points : MAJEURE.MINEURE.CORRECTIF.
- MAJEURE — incrémentée lorsque vous faites des changements d'API incompatibles. Passer de 1.x.x à 2.0.0 signale que le code existant peut se casser
- MINEURE — incrémentée lorsque vous ajoutez des fonctionnalités de manière rétrocompatible. Passer de 1.2.x à 1.3.0 signifie de nouvelles fonctionnalités sans casser les existantes
- CORRECTIF — incrémenté lorsque vous faites des corrections de bugs rétrocompatibles. Passer de 1.2.3 à 1.2.4 signifie que seuls des bugs ont été corrigés
- Chaque composante doit être un entier non négatif et ne doit pas contenir de zéros initiaux (1.02.3 est invalide)
Essayez gratuitement — sans inscription
Valider une version SemVer →Plages de versions
Les gestionnaires de paquets utilisent des plages de versions pour spécifier les versions de dépendances compatibles. Comprendre ces plages est essentiel pour des builds fiables.
- Plages avec accent circonflexe (^1.2.3) — permettent des changements qui ne modifient pas le chiffre non nul le plus à gauche. ^1.2.3 signifie toute version de 1.2.3 jusqu'à mais non compris 2.0.0
- Plages avec tilde (~1.2.3) — n'autorisent que les changements au niveau du correctif. ~1.2.3 signifie toute version de 1.2.3 jusqu'à mais non compris 1.3.0
- Version exacte (1.2.3) — seule cette version spécifique est acceptable, sans flexibilité
Cas d'utilisation
Le versionnage sémantique est le fondement de la gestion moderne des paquets et des workflows de publication.
- npm, pip et Cargo — les gestionnaires de paquets s'appuient sur SemVer pour résoudre les arbres de dépendances et empêcher les changements incompatibles d'atteindre la production
- Pipelines CI/CD — les systèmes automatisés utilisent les balises SemVer pour déclencher des builds, publier des versions et générer des journaux de modifications
- Versionnage d'API — les API REST utilisent des versions majeures dans les URL (v1, v2) pour maintenir la rétrocompatibilité tout en évoluant
- Auteurs de bibliothèques — publier une bibliothèque avec un SemVer approprié signale aux consommateurs quand les mises à niveau sont sûres
Pre-release et metadonnees
SemVer prend en charge deux extensions optionnelles qui ajoutent du contexte aux numéros de version sans affecter les règles de précédence.
- Identifiants de pré-version — ajoutés après un trait d'union : 1.0.0-alpha, 1.0.0-beta.2, 1.0.0-rc.1. Ils indiquent des versions qui ne sont pas encore stables et ont une précédence inférieure à la version associée
- Métadonnées de build — ajoutées après un signe plus : 1.0.0+build.123, 1.0.0-beta+exp.sha.5114f85. Les métadonnées de build sont ignorées lors de la détermination de la précédence des versions
- Les versions de pré-version sont triées à l'aide d'identifiants séparés par des points : les identifiants numériques sont triés numériquement, les identifiants alphanumériques sont triés lexicalement
FAQ
La version 0.x.x est-elle traitée différemment de 1.x.x ?
Oui. Dans SemVer, la version 0.x.x indique le développement initial où tout peut changer à tout moment. L'API publique ne doit pas être considérée comme stable. Une fois que vous publiez 1.0.0, vous vous engagez à suivre les règles SemVer pour toutes les versions suivantes.
Puis-je utiliser v comme préfixe (v1.2.3) ?
La spécification SemVer n'inclut pas de préfixe v — le format canonique est 1.2.3. Cependant, de nombreux outils (balises Git, versions GitHub) utilisent conventionnellement v1.2.3. La plupart des validateurs acceptent les deux formes.
Que se passe-t-il si j'oublie d'incrémenter la version majeure pour un changement incompatible ?
Les consommateurs qui utilisent des plages avec accent circonflexe recevront automatiquement la mise à jour et leurs builds peuvent se casser de manière inattendue. C'est pourquoi la discipline SemVer est critique — c'est un contrat social entre les auteurs de bibliothèques et les consommateurs.