Calculatrice Semver

Calculatrice de versionnage sémantique — bumper les versions, analyser les chaînes semver et vérifier si une version satisfait une plage de versions.

Parsed Version

Major

1

Minor

2

Patch

3

Bumped Versions

Patch1.2.4Bug fix / minor change
Minor1.3.0New feature (backwards compatible)
Major2.0.0Breaking change

Version Range Checker

Satisfies

Comment utiliser Calculatrice Semver

  1. 1Entrez une chaîne de version sémantique (par exemple, 1.2.3).
  2. 2Consultez les versions bumped majeures, mineures et patch.
  3. 3Entrez une plage de versions pour vérifier la compatibilité.
  4. 4Ajoutez des identifiants de préversion et des métadonnées de build.
ZenovayAnalytics

Voyez qui est sur votre site en ce moment.

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

Questions fréquemment posées

Qu'est-ce que le versioning sémantique ?
Le versioning sémantique (semver) est un schéma de versioning avec le format MAJOR.MINOR.PATCH : MAJOR — changements d'API incompatibles ; MINOR — nouvelles fonctionnalités rétrocompatibles ; PATCH — corrections de bugs rétrocompatibles. Par exemple : 1.0.0 → 1.0.1 (correction de patch), 1.0.1 → 1.1.0 (nouvelle fonctionnalité), 1.1.0 → 2.0.0 (changement cassant). Les versions de pré-release utilisent un tiret : 1.0.0-alpha.1, 1.0.0-beta.2, 1.0.0-rc.1. Les métadonnées de build utilisent + : 1.0.0+build.123.
Que signifient les spécificateurs de plage de version npm ?
^1.2.3 (caret) — permet les mises à jour MINOR et PATCH : >=1.2.3 <2.0.0. Couramment utilisé dans package.json. ~1.2.3 (tilde) — permet seulement les mises à jour PATCH : >=1.2.3 <1.3.0. Plus strict. >=1.2.3 — n'importe quelle version à ou au-dessus. 1.2.3 — version exacte seulement. * — n'importe quelle version. 1.x ou 1.X — n'importe quel patch pour major 1. 1.2.x — n'importe quel patch pour 1.2. Les plages peuvent être combinées : >=1.0.0 <2.0.0 (équivalent à ^1.0.0 pour major non-zéro).
Quand devrais-je incrémenter major vs minor vs patch ?
Incrémenter PATCH pour : corrections de bugs, correctifs de sécurité, améliorations de performance, modifications de documentation — rien qui change l'API publique. Incrémenter MINOR pour : nouvelles fonctionnalités, nouvelles fonctions/méthodes, dépréciation de la fonctionnalité existante (mais pas suppression) — tout rétrocompatible. Incrémenter MAJOR pour : suppression ou renommage d'API publiques, modification des signatures de fonction de manière incompatible, modification du comportement par défaut qui était auparavant stable. En cas de doute, utilisez MINOR — vous pouvez toujours sortir une MAJOR plus tard si nécessaire.
Quelle est la différence entre le versioning 0.x.y et 1.x.y ?
Selon semver, 0.MAJOR.MINOR indique le développement initial où tout peut changer. La sémantique standard patch/minor/major ne s'applique pas strictement en dessous de 1.0.0 — les changements cassants peuvent se produire dans les incrémentations MINOR. De nombreux projets utilisent 0.x.y pendant le développement et sortent 1.0.0 quand l'API est stable. npm et d'autres gestionnaires de paquets respectent cela et traitent ^0.1.0 comme >=0.1.0 <0.2.0 (pas le comportement caret habituel), rendant ^0.x.y effectivement un tilde.
Qu'est-ce qu'un release candidate et quand devrais-je l'utiliser ?
Un release candidate (rc) est une version de pré-release qui pourrait devenir la version finale si aucun bug n'est trouvé : 1.0.0-rc.1, 1.0.0-rc.2. La progression de pré-release va généralement : alpha (tôt, instable) → beta (fonctionnellement complet, peut avoir des bugs) → rc (candidate prête pour la production). Les versions de pré-release ont une précédence inférieure à la version : 1.0.0-rc.1 < 1.0.0. Elles sont exclues de la résolution de plage semver de la plupart des gestionnaires de paquets à moins d'être explicitement demandées.