guides

Le versionnage sémantique, presque toujours abrégé en SemVer, est un ensemble simple de règles pour numéroter les versions logicielles de sorte que le numéro de version lui-même vous dise ce qui a changé. Au lieu d'un compteur dénué de sens, une version SemVer se compose de trois nombres - MAJOR.MINOR.PATCH, comme 2.4.1 - et chaque position a une signification définie. Une fois que vous connaissez les règles, vous pouvez regarder une montée de version et comprendre immédiatement si une mise à jour est sûre, ajoute des fonctionnalités ou risque de casser votre code.

Les trois parties répondent chacune à une question différente. MAJOR (le premier nombre) augmente lorsque vous apportez des changements incompatibles et cassants à l'API publique - la mise à niveau peut vous obliger à modifier votre propre code. MINOR (le deuxième) augmente lorsque vous ajoutez de nouvelles fonctionnalités de manière rétrocompatible - de nouvelles fonctionnalités que vous pouvez adopter ou ignorer. PATCH (le troisième) augmente pour des corrections de bogues rétrocompatibles - des corrections sûres qui ne changent pas la façon dont le logiciel est utilisé.

Il y a deux règles mécaniques qui font trébucher les gens. Lorsque vous augmentez MAJOR, vous remettez MINOR et PATCH à zéro : après 1.4.2, un changement cassant devient 2.0.0, et non 2.4.2. Lorsque vous augmentez MINOR, vous remettez PATCH à zéro : après 1.4.2, une nouvelle fonctionnalité devient 1.5.0. Ainsi, les nombres à droite recommencent toujours à zéro quand un nombre à leur gauche augmente.

SemVer a aussi une règle spéciale pour le développement initial. Toute version commençant par 0 - comme 0.3.1 - est considérée comme instable, et les garanties normales ne s'appliquent pas pleinement. Pendant la phase 0.x, l'API peut changer à tout moment, alors traitez ces versions avec prudence. Le passage à 1.0.0 est un signal délibéré : cela signifie que l'auteur s'engage à fournir une API publique stable et à suivre les règles SemVer à partir de ce moment.

Au-delà des trois nombres fondamentaux, SemVer prend en charge les étiquettes de pré-version et de build. Une pré-version ajoute un trait d'union et un identifiant, comme 1.0.0-alpha, 1.0.0-beta.2 ou 1.0.0-rc.1, et elle a une priorité inférieure à la version finale - ainsi 1.0.0-rc.1 vient avant 1.0.0. Des métadonnées de build peuvent être ajoutées après un signe plus, comme 1.0.0+20260715, mais elles sont ignorées lors de la comparaison des versions. Cela permet aux équipes de livrer des builds de test sans prétendre qu'il s'agit de versions terminées.

La raison pour laquelle tout ceci compte, c'est la gestion des dépendances. Lorsque votre projet dépend d'une bibliothèque, vous fixez rarement une version exacte pour toujours ; vous autorisez une plage. Les gestionnaires de paquets utilisent SemVer pour rendre ces plages sûres. Dans npm, par exemple, une plage à accent circonflexe comme ^1.2.3 signifie toute version à partir de 1.2.3 jusqu'à, mais sans inclure, 2.0.0 - toutes les mises à jour rétrocompatibles, aucune des cassantes. Une plage à tilde comme ~1.2.3 est plus stricte, autorisant les mises à jour de correctif jusqu'à, mais sans inclure, 1.3.0.

Ces plages ne fonctionnent que parce que tout le monde s'accorde sur ce que signifie une montée de version. Si une bibliothèque livre un changement cassant mais n'incrémente que PATCH, elle peut casser silencieusement chaque projet qui a fait confiance à la plage. C'est le contrat social au coeur de SemVer : le numéro est une promesse de compatibilité, et l'honorer est ce qui empêche tout l'écosystème des mises à jour automatiques de s'effondrer.

SemVer est défini par une spécification courte et lisible sur semver.org, et c'est le schéma utilisé par npm, Cargo et d'innombrables autres registres de paquets et outils. Ce n'est pas la seule façon de versionner un logiciel - certains projets utilisent le versionnage par calendrier (comme 2026.07) ou leur propre schéma - mais SemVer est le plus largement compris, et le connaître rend la lecture des journaux de modifications et des plages de dépendances bien plus facile.

L'enseignement pratique : lisez une version comme une phrase. Un saut du premier nombre dit de s'arrêter et de vérifier les changements cassants avant de mettre à niveau. Un saut du deuxième dit qu'il y a de nouvelles fonctionnalités mais que votre code existant est sûr. Un saut du troisième dit qu'il s'agit d'une correction de bogue sûre. Cette seule habitude - lire la position qui a changé - transforme un nombre opaque en un message clair sur le risque.