Comparateur de Versions SemVer | Détermine quelle version est la plus récente selon SemVer 2.0.0

Analyse deux chaînes de version selon la spécification SemVer 2.0.0, les sépare en major / minor / patch / pre-release / build et renvoie un verdict de précédence strict. Des cas comme 1.2.3 face à 1.10.0-rc.1 deviennent transparents grâce à un symbole et à la ventilation des composants.

💡 À propos de cet outil

Comparer des versions n'est pas la même chose que trier du texte. Si tu compares 1.9.0 et 1.10.0 comme de simples chaînes, le 9 paraît plus grand que le 1, donc 1.9.0 l'emporterait, ce qui est faux. SemVer compare le champ mineur de façon numérique, si bien que 1.10.0 est la version la plus récente. Ce piège du « 9 contre 10 » est exactement ce qui surprend lors de la relecture d'un diff de lockfile ou au moment de décider si une mise à jour est sûre.

Colle deux versions et l'outil analyse chacune, compare major / minor / patch comme des entiers, puis applique les règles de précédence des pre-releases, renvoyant A < B, A = B ou A > B. Chaque version est décomposée en ses composants dans une carte verticale pour que tu voies pourquoi le verdict tombe ainsi. Les métadonnées de build (tout ce qui suit +) sont ignorées pour la précédence selon la spécification, et la ventilation le montre clairement.

🧐 Questions fréquentes

1.0.0-alpha est-elle plus ancienne ou plus récente que 1.0.0 ? 1.0.0 est plus récente. Une version pre-release a toujours une précédence inférieure à la version normale qui partage le même major.minor.patch.

Comment 1.0.0-alpha.1 se compare-t-elle à 1.0.0-alpha.beta ? Les identifiants sont découpés par points et comparés de gauche à droite. Les identifiants numériques se comparent numériquement, ceux qui contiennent des lettres se trient en ordre ASCII, et un identifiant purement numérique a toujours une précédence plus basse qu'un identifiant contenant des lettres.

Deux versions qui ne diffèrent que par les métadonnées de build sont-elles considérées comme différentes ? Non. 1.0.0+build.1 et 1.0.0+build.999 ont une précédence égale (A = B). Les métadonnées de build sont exclues de la comparaison.

Puis-je coller v1.2.3 avec le v initial ? Oui : un préfixe v, V ou = est retiré avant l'analyse. La chaîne nettoyée doit rester un SemVer 2.0.0 valide (MAJOR.MINOR.PATCH).

Et une chaîne courte comme 1.2 ou 1 ? SemVer 2.0.0 exige les trois nombres, donc 1.2 est considéré comme invalide. Complète-la en 1.2.0 et elle sera analysée.

📚 Le saviez-vous : l'algorithme de précédence

SemVer, publié par le cofondateur de GitHub Tom Preston-Werner, donne un sens partagé aux nombres MAJOR.MINOR.PATCH : incrémente MAJOR pour les changements cassant la compatibilité, MINOR pour les fonctionnalités rétrocompatibles, PATCH pour les corrections rétrocompatibles. Des gestionnaires comme npm et Cargo s'appuient sur cette sémantique pour résoudre les plages de dépendances.

Le point le plus souvent mal compris est l'ordre des pre-releases. La spécification définit un algorithme précis : lorsque tous les identifiants précédents sont égaux, l'ensemble comportant le plus de champs de pre-release possède la précédence la plus élevée, si bien que 1.0.0-alpha.1 est antérieure à 1.0.0-alpha.1.1. Comme ces règles se retiennent mal, placer deux versions côte à côte et lire la ventilation est une vérification rapide avant de faire confiance à un comparateur enfoui dans un script de CI.