ZenovayTools

Comparateur Semver

Comparez les numéros de version sémantique. Analysez et triez les chaînes semver, vérifiez si une version satisfait une plage et comprenez les différences majeures/mineures/patch.

Compare Two Versions

1.2.3
OLDER
2.0.0-beta.1
MAJOR version change
MajorMinorPatchPre-release
1.2.3123—
2.0.0-beta.1200beta.1

Version Range Check

✓ 1.5.0 satisfies ^1.2.0

Sort Version List

One version per line — sorted newest first

13.0.0-beta.1beta.1
22.1.0
32.1.0-11
42.0.0-rc.1rc.1
51.2.3
61.0.0
71.0.0-betabeta
81.0.0-alphaalpha

Comment utiliser Comparateur Semver

  1. 1Entrez deux numéros de version à comparer (par exemple 1.2.3 vs 2.0.0).
  2. 2Consultez lequel est plus récent et ce qui a changé (majeure/mineure/patch).
  3. 3Triez une liste de versions semver.
  4. 4Vérifiez si une version satisfait une contrainte de plage comme ^1.2.0.
ZenovayAnalytics

Analytics pensé pour les fondateurs.

  • Suivi des visiteurs en temps réel
  • Vie privée d'abord, sans bandeau cookies
  • Installé en deux minutes
Découvrir Zenovay

Outils connexes

Formateur et Validateur JSON
Formatez, validez et embellissez les données JSON avec la coloration syntaxique et la détection d'erreurs.
Décodeur JWT
Décodez et inspectez les jetons JWT. Consultez l'en-tête, la charge utile et vérifiez les signatures.
Encodeur/Décodeur Base64
Encodez du texte en Base64 ou décodez Base64 en texte. Supporte UTF-8 et les données binaires.
Encodage / Décodage URL
Encodez ou décodez les composants URL. Traitez les caractères spéciaux, les chaînes de requête et les URL complètes.

Questions fréquemment posées

Qu'est-ce que le versioning sémantique ?▾
Le versioning sémantique (semver) est une convention de versioning utilisant le format MAJOR.MINOR.PATCH. MAJOR : changements d'API incompatibles (cassants). MINOR : nouvelles fonctionnalités rétrocompatibles. PATCH : corrections de bugs rétrocompatibles. Les versions de pré-release ajoutent un tiret et des identifiants : 1.0.0-alpha, 1.0.0-beta.1, 1.0.0-rc.1. Les métadonnées de build ajoutent un signe plus : 1.0.0+build.42. Défini sur semver.org par Tom Preston-Werner (co-fondateur de GitHub).
Comment les versions semver sont-elles comparées ?▾
Les versions sont comparées de gauche à droite : MAJOR d'abord, puis MINOR, puis PATCH. Quand ceux-ci sont égaux, une version de pré-release a une précédence inférieure à la version : 1.0.0-alpha < 1.0.0. Les identifiants de pré-release sont comparés comme nombres s'ils sont numériques, sinon lexicographiquement comme chaînes. La pré-release plus longue a une précédence plus élevée quand tous les champs précédents correspondent : 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2.
Que signifient les opérateurs de plage de version npm ?▾
^1.2.3 (caret) : compatible avec, permet les mises à jour MINOR et PATCH — ≥1.2.3 <2.0.0. ~1.2.3 (tilde) : approximativement équivalent, permet seulement les mises à jour PATCH — ≥1.2.3 <1.3.0. 1.2.x ou 1.2.* : n'importe quel PATCH. * ou x : n'importe quelle version. >1.2.3, >=1.2.3, <2.0.0 : plages explicites. 1.2.3 - 2.3.4 : plage inclusive. Ces plages sont évaluées par npm, Yarn, pnpm, et des outils comme Renovate et Dependabot.
Quand devrais-je incrémenter MAJOR vs MINOR vs PATCH ?▾
MAJOR (x.0.0) : quand vous faites des changements d'API incompatibles — fonctions supprimées, signatures de fonction modifiées, changements de comportement cassants, drapeaux CLI supprimés. MINOR (1.x.0) : quand vous ajoutez des fonctionnalités de manière rétrocompatible — nouvelles fonctions, nouveaux paramètres optionnels, nouvelles options de configuration. PATCH (1.0.x) : quand vous faites des corrections de bugs rétrocompatibles — correction du comportement incorrect, correctifs de sécurité, améliorations de performance sans changement d'API.
Quelle est la différence entre la pré-release et les métadonnées de build ?▾
Pré-release (1.0.0-alpha.1) : affecte la précédence de version — 1.0.0-alpha.1 < 1.0.0. Utilisée pour alpha, beta, release candidates. Métadonnées de build (1.0.0+build.1) : n'affectent PAS la précédence de version — 1.0.0+build.1 == 1.0.0 aux fins de comparaison. Les métadonnées de build sont souvent utilisées pour les numéros de build CI, les hashes de commits git, ou les horodatages de build. Selon la spec semver, deux versions différant seulement dans les métadonnées de build sont égales.