Comparez des versions sémantiques selon les règles SemVer
Sachez laquelle de deux versions passe vraiment en premier : 1.0.0-alpha.1 est inférieure à 1.0.0-alpha.beta, car une étiquette numérique se classe toujours sous un mot, et 2.10.0 dépasse bien 2.9.0. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Première version
- 1.0.0-alpha.1
- Deuxième version
- 1.0.0-alpha.beta
- Comparaison
- less
- Précédence
- -1
- Version supérieure
- 1.0.0-alpha.beta
Comparez deux numéros de version sémantique sans dépendre d’un tri lexical, d’une conversion en virgule flottante ou de raccourcis propres à un gestionnaire de paquets. Cette capacité valide les deux entrées selon Semantic Versioning 2.0.0, puis applique les règles officielles de priorité aux composantes majeure, mineure, corrective et de préversion. Elle indique si la première version est inférieure, supérieure ou équivalente à la seconde, tout en ignorant correctement les métadonnées de compilation. Toute version invalide ou incomplète produit une erreur de saisie claire plutôt qu’un classement trompeur.
Comparez les versions selon les règles des logiciels publiés
Une comparaison de chaînes ordinaire donne un résultat erroné pour de nombreux numéros de version. Un tri lexical peut, par exemple, placer 2.10.0 avant 2.9.0 parce qu’il compare le caractère 1 au caractère 9, tandis qu’une conversion numérique efface le rôle distinct des positions majeure, mineure et corrective. Ce comparateur analyse séparément chaque position obligatoire et les compare de gauche à droite.
Il refuse également les formes approximatives, comme une composante corrective absente, un v initial ou un identifiant numérique principal précédé d’un zéro. Cette validation stricte est utile dans les scripts de déploiement, registres de paquets, services de mise à jour et contrôles CI : des données mal formées ne peuvent pas être prises silencieusement pour une publication valide. Envoyez les deux versions exactement comme elles sont publiées.
Le résultat fournit une priorité signée : moins un signifie que la première est inférieure, zéro qu’elles sont équivalentes et un que la première est supérieure. Un champ descriptif facilite aussi son emploi dans les interfaces et conditions de workflow.
Maîtrisez l’ordre des préversions et les métadonnées
Les identifiants de préversion sont la principale source d’erreurs des comparateurs simplistes. Une publication dotée d’un suffixe de préversion est moins prioritaire que la même version majeure, mineure et corrective sans suffixe : 1.0.0-rc.1 est donc inférieur à 1.0.0. Lorsque les deux versions sont préliminaires, leurs identifiants sont comparés successivement.
Les identifiants numériques sont classés selon leur valeur, les autres selon l’ordre lexical ASCII, et un identifiant numérique est toujours inférieur à un identifiant non numérique. Si tous les identifiants communs correspondent, la version qui en possède davantage est supérieure. Ces règles reproduisent la progression standard d’alpha à beta puis aux versions candidates, sans attribuer de sens particulier aux mots.
Les métadonnées suivant le signe plus sont validées, mais exclues de la priorité. Ainsi, 1.0.0+linux et 1.0.0+windows sont équivalents malgré leurs chaînes différentes.
Automatisez en toute sécurité avec une comparaison stricte
Un résultat déterministe peut devenir un point de décision simple et fiable au sein d’un système plus vaste. Une chaîne de publication peut exiger que la version proposée soit supérieure à celle qui est déployée. Un programme de mise à jour peut déterminer si un manifeste téléchargé correspond à une mise à niveau, un retour en arrière ou une compilation équivalente.
Une suite de tests peut couvrir l’enchaînement canonique des préversions et refuser les étiquettes invalides avant la publication des artefacts. L’implémentation n’effectue aucune requête réseau, ne consulte aucune horloge et n’emploie aucune valeur aléatoire : les mêmes entrées produisent toujours la même sortie. Les identifiants numériques sont comparés comme des chaînes de chiffres plutôt que convertis en nombres JavaScript, ce qui préserve l’ordre même au-delà de la plage des entiers sûrs.
La longueur des entrées est limitée afin de borner le traitement.
Cas d’usage
Sécurisez une chaîne de publication
Vérifiez qu’une version de paquet proposée est supérieure à la version déployée avant de la publier.
Évaluez les manifestes de mise à jour
Déterminez si une publication distante est une mise à niveau, un retour ou une compilation équivalente sans influence des métadonnées.
Validez les suites de préversions
Testez l’ordre des versions alpha, beta, candidates et finales, tout en refusant les chaînes Semantic Versioning incorrectes.
Questions fréquentes
Que signifie la valeur de comparaison ?
Une priorité de -1 signifie que la première version est inférieure, 0 qu’elles sont équivalentes et 1 que la première est supérieure.
Les métadonnées de compilation influencent-elles le résultat ?
Non. Elles sont validées, mais Semantic Versioning les exclut des comparaisons de priorité.
Une préversion est-elle inférieure à la version finale correspondante ?
Oui. À numéros majeur, mineur et correctif identiques, une version avec des identifiants préliminaires est moins prioritaire que la finale.
Les zéros initiaux sont-ils autorisés ?
Les identifiants numériques majeurs, mineurs, correctifs et de préversion ne peuvent pas commencer par zéro, sauf s’ils valent exactement zéro.
Puis-je ajouter un v initial ou omettre le numéro correctif ?
Non. Les entrées doivent être des chaînes Semantic Versioning 2.0.0 strictes, comme 1.2.3 ou 1.2.3-rc.1.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/dev2/semver-compare \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"first_version":"2.1.0-rc.1","second_version":"2.1.0"}'const res = await fetch("https://api.kit.forhosting.com/dev2/semver-compare", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"first_version": "2.1.0-rc.1",
"second_version": "2.1.0"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev2/semver-compare",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"first_version": "2.1.0-rc.1",
"second_version": "2.1.0"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/semver-compare", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"first_version":"2.1.0-rc.1","second_version":"2.1.0"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"first_version":"2.1.0-rc.1","second_version":"2.1.0"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/semver-compare", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"first_version": "2.1.0-rc.1",
"second_version": "2.1.0"
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.semver_compare",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Limites
max_chars_per_version | 1024 |
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Maîtrisez l’ordre des préversions et les métadonnées
Si la priorité est égale, greater_version vaut null, car aucune entrée ne surpasse l’autre.
Automatisez en toute sécurité avec une comparaison stricte
Utilisez l’exécuteur du navigateur pour une vérification interactive ou appelez l’API pour $0.002 dans un workflow reproductible. Considérez invalid_input comme un défaut de qualité à corriger.
Questions techniques
Quel est le tarif ?
Le tarif de l’API est de $0.002 par comparaison. L’exécuteur du navigateur permet les vérifications interactives.