Vérifier une version dans une plage SemVer

Ce vérificateur y répond selon l’ordre déterministe de SemVer. Il comprend les comparateurs, les intersections séparées par des espaces, les plages avec trait d’union, les jokers, les versions partielles et les alternatives à double barre. Les identifiants de préversion et de build gardent leur sens sémantique exact ; le résultat convient donc aux outils de dépendances et non à une simple approximation numérique.

Saisissez une version et la plage à contrôler

Indiquez une version sémantique complète telle que <code>2.4.1</code>, puis une expression de plage. Dans un ensemble de comparateurs séparés par des espaces, chaque condition doit réussir : <code>&gt;=2.0.0 &lt;3.0.0</code> accepte ainsi les versions stables de la deuxième version majeure. Séparez les ensembles par <code>||</code> lorsqu’une seule branche suffit. Une version exacte constitue également une plage valide. Le résultat contient la version normalisée, la plage sans espaces extérieurs, un booléen et le numéro, à partir de un, de l’alternative correspondante ; zéro signale qu’aucune branche ne convient. Cette réponse explicite s’intègre facilement dans une règle de déploiement, un rapport de dépendances, un éditeur de manifeste ou un test, sans analyser de prose. Les entrées restent des chaînes : convertir une version entière en nombre flottant ferait paraître 1.10 inférieur à 1.9 et supprimerait les préversions. Un <code>v</code> initial est accepté sur une version complète puis retiré ; les composants mal formés, alternatives vides et identifiants incorrects déclenchent une erreur de saisie typée plutôt qu’un faux résultat trompeur.

Maîtrisez comparateurs, plages à trait d’union et jokers

Vous pouvez employer <code>&gt;</code>, <code>&gt;=</code>, <code>&lt;</code>, <code>&lt;=</code> ou <code>=</code>. Plusieurs comparateurs dans une alternative forment une intersection. Une expression comme <code>1.2.3 - 2.4.0</code> inclut ses deux bornes complètes ; une borne supérieure partielle s’étend jusqu’à la fin de sa famille : <code>1.2 - 2.4</code> commence à 1.2.0 et s’arrête avant 2.5.0. Les jokers s’écrivent <code>x</code>, <code>X</code> ou <code>*</code>. Ainsi, <code>3.x</code> couvre les versions stables de 3.0.0 jusqu’avant 4.0.0, tandis que <code>3.2</code> équivaut à <code>3.2.x</code>. Un joker doit suivre les composants connus ; <code>1.x.4</code> est refusé, car il ne décrit aucun intervalle cohérent. Cette capacité refuse volontairement les raccourcis avec accent circonflexe ou tilde. Exprimez ces limites au moyen de comparateurs explicites afin que la règle évaluée demeure lisible et sans ambiguïté dans les journaux, politiques produites, contrôles automatiques et revues humaines.

Comprenez l’ordre, les préversions et les métadonnées

Les versions sémantiques se comparent composant par composant, et non par ordre alphabétique. Les nombres majeur, mineur et correctif décident d’abord. Une préversion précède la version stable correspondante ; ses identifiants séparés par des points se comparent de gauche à droite : les éléments numériques suivent leur valeur, précèdent les éléments non numériques, et le préfixe identique le plus court vient en premier. Les métadonnées après <code>+</code> restent dans la sortie normalisée mais ne modifient jamais la priorité, conformément à SemVer. Les gestionnaires de dépendances empêchent aussi la sélection accidentelle de préversions. Le vérificateur applique cette règle : une préversion ne satisfait un ensemble que si celui-ci mentionne une préversion ayant les mêmes nombres majeur, mineur et correctif. Par exemple, <code>2.0.0-beta.2</code> peut satisfaire <code>&gt;=2.0.0-beta.1 &lt;2.0.0</code>, mais n’entre pas dans un joker général uniquement parce que son noyau numérique correspond. Toute évaluation est locale et déterministe. Aucun registre n’est interrogé, aucun paquet téléchargé et aucune version actuelle supposée ; les mêmes chaînes produisent toujours la même décision.