Le Semantic Versioning, plus connu sous le nom de SemVer, est une convention assez simple : avoir des numéros qui indiquent ce qui change.
L’idée n’est pas d’être parfait, mais d’être prévisible pour celles et ceux qui consomment une lib ou un package.
Aux origines
Le Semantic Versioning est formalisé autour de 2010 par Tom Preston-Werner, cofondateur de GitHub.
À l’époque, le problème est simple :
- les numéros de version sont utilisés de manière incohérente,
- il est difficile de savoir si une mise à jour va casser une application,
- les gestionnaires de dépendances commencent à automatiser les mises à jour, sans information fiable sur leur impact.
L’objectif de cette convention est donc de donner du sens aux numéros de version, afin qu’ils deviennent exploitables par les humains et par les outils.
MAJEURE.MINEURE.CORRECTIF
- MAJEURE : changements incompatibles avec les versions précédentes
- MINEURE : nouvelles fonctionnalités rétrocompatibles
- CORRECTIF : corrections de bugs rétrocompatibles
Cette simplicité est l’une des raisons majeures de son adoption massive.
Une convention
Un point fondamental : ce système n’est pas un standard technique et n’est imposé par aucune autorité.
La spécification officielle parle explicitement de :
- règles,
- recommandations,
- bonnes pratiques.
Cette convention repose entièrement sur la discipline et la bonne foi des mainteneurs.
Le cœur de la convention : la notion d’API publique
Elle suppose l’existence d’une API publique clairement définie.
Une API est un outil informatique qui permet à un site internet ou à un logiciel de communiquer avec un autre ordinateur et échanger des données.
Source incroyable : https://api.gouv.fr/apropos
C’est cette API qui sert de référence pour décider :
- si un changement est majeur,
- mineur,
- ou correctif.
En pratique, modifier un comportement interne non documenté n’est pas considéré comme un breaking change au regard de l’API publique, même si cela casse le code de certains utilisateurs.
Elle ne protège donc pas les usages implicites, détournés ou non documentés.
C’est un engagement moral, pas une garantie contractuelle.
Le cas particulier des versions 0.x
La spécification est très claire sur ce point : avant la version 1.0.0, l’API est considérée comme instable.
On reviendra sur ce point dans l'article : Guide du SemVer avec npm.
Conclusion
Le SemVer est née d’un besoin très concret : rendre les mises à jour plus prévisibles dans un monde de dépendances automatisées.
Il apporte un langage commun, une structure simple et surtout une convention.
Mais attention, ça ne fonctionne que si l'ensemble de la chaîne la respecte.
En résumé, cette convention aide à faire confiance… mais ne dispense jamais de vérifier.
Merci d'avoir lu cet article !
Il a été posté initialement sur mon blog : https://616.earth/semver-les-bases
Sources
Spécification officielle du Semantic Versioning,
https://semver.org/Documentation npm – Semantic Versioning, & ranges
https://docs.npmjs.com/about-semantic-versioningTom Preston-Werner – Semantic Versioning,
https://tom.preston-werner.com/2010/08/23/semantic-versioning.htmlHynek Schlawack – Semantic Versioning, Will Not Save You
https://hynek.me/articles/semver-will-not-save-you/Discussions communautaires sur les limites du SemVer
https://clojureverse.org/t/stop-using-semantic-versioning-any-writings-on-this/9951
Top comments (0)