セマンティックバージョン 解析・比較

セマンティックバージョン解析ツールとは？#

Semantic Versioning（SemVer）は、ほとんどのライブラリがリリースに含まれる変更の種類をシグナルするために使う major.minor.patch の慣習です。バグ修正は patch を、後方互換の追加は minor を、破壊的変更は major を上げます。プレリリースタグ（1.0.0-beta.1）やビルドメタデータ（+exp.sha.1）を加えると、semver.org 2.0.0 で定義される完全な文法になります。

厄介なのは、「2 つのバージョンを比較する」と「このバージョンは依存関係の範囲を満たすか」が、目で見て間違えやすいことです。1.0.0 は 1.0.0-beta より高いですか低いですか？（高い — リリースは常にプレリリースより上位。）1.2.3 は ^1.2.0 を満たしますか？（はい。）~1.2.0 を満たしますか？（これもはいですが、より狭い理由から。）本ページはバージョンを仕様が定義する通りに解析し、構成要素を示し、2 つのバージョンを優先度で比較し、package.json が使うのと同じ ^／~／>=／||／ハイフン構文で範囲クエリに答えます — すべてローカルで、推測ではなく実際のルールに対して。

使い方#

1. 上部のクイック入力ボタンで一般的な例をドロップするか、直接入力します。
2. 2 つの入力にバージョン A とバージョン B を入力します。先頭の v や = は受け付けられて剥がされ、1.2.3-beta.1+build.42 は構成要素まで解析されます。
3. 満足度チェックをしたい場合は範囲式を入力します。デフォルトは ^1.2.0 || >=2.0.0 <3.0.0 — 実際の依存関係範囲が書かれるのと同じ、2 つの OR セット。対応構文: ^（キャレット）、~（チルダ）、>= <= > < =、x／X／* ワイルドカード、部分バージョン（1.2）、- ハイフン範囲、|| でセットを OR。
4. 2 つの解析カードを読みます。それぞれに正規 clean 形式と、major、minor、patch、prerelease、build の各フィールドが示されます。無効なバージョンはカードがメッセージ付きで赤になります。
5. 比較カードを読みます。優先度で A < B、A = B、A > B を示し、diff — 変わった最上位の構成要素（major、minor、patch、prerelease、build）— を加えます。
6. 範囲チェックカードを読みます。入力した範囲について、A が満たすか、B が満たすかを告げます。

主な機能#

• 仕様通りの優先度。 比較は major.minor.patch を歩き、続いてプレリリース識別子を歩き、プレリリースのないバージョンがあるバージョンより常に上位というルールを適用します。数値識別子は数値的に比較され（beta.2 < beta.11）、英数字は辞書順に比較され、数値は常に英数字より下位になります。ビルドメタデータは解析・表示されますが優先度には影響しません。
• キャレットとチルダを正しく脱糖。 ^1.2.3 は >=1.2.3 <2.0.0 に、^0.2.3 は >=0.2.3 <0.3.0 に、^0.0.3 は >=0.0.3 <0.0.4 になります — キャレットの「左端の非ゼロ」ルール。チルダは同じマイナーに固定します: ~1.2.3 は >=1.2.3 <1.3.0。
• ||、ハイフン、ワイルドカード付きの範囲。 ^1.0.0 || >=2.0.0 <3.0.0（2 セットの OR）、1.2.0 - 1.5.0（両端を含むハイフン範囲）、1.x／1.2.*（ワイルドカード範囲）がすべて解析・テストされます。
• プレリリース包含ゲート。 プレリリースバージョンが範囲を満たせるのは、同じセット内の比較子が同じ major.minor.patch にプレリリースタグを持つときだけです。だから 1.5.0-rc.1 は ^1.2.0 を満たしませんが、^1.5.0-rc.0 は満たします — 実際のパッケージマネージャがランダムなプレリリースをリリースビルドに入れない方法と一致します。
• 物語を語る diff。 diff フィールドは変わった最上位の構成要素を報告するため、1.2.3 から 2.0.0 への jump は major を示し、ビルドだけが変わった 1.0.0 から 1.0.0 へは、優先度は不変でも build を示します。
• 寛容な入力。 先頭の v、先頭の =、前後の空白は許容されるため、git タグや変更履歴からコピーしたバージョンが手作業のクリーンアップなしで解析されます。

実例#

デフォルト — A 1.2.3、B 2.0.0、範囲 ^1.2.0 || >=2.0.0 <3.0.0 — で、ページは次を報告します。

A clean    1.2.3        (major 1, minor 2, patch 3)
B clean    2.0.0        (major 2, minor 0, patch 0)
compare    1.2.3  <  2.0.0
diff       major
range      A satisfies   B satisfies

両バージョンが範囲を満たしますが、理由は異なります。A は最初の OR セット（^1.2.0 → >=1.2.0 <2.0.0）に入り、B は 2 つ目（>=2.0.0 <3.0.0）に入ります。B を 3.0.0 に変えるとバッジが満たさないに切り替わります — 上限 <3.0.0 が除外するためです。

プレリリースルールの実例を見るには、A を 1.5.0-rc.1、B を 1.5.0 にし、範囲を ^1.5.0-rc.0 のままにします。A は満たします（同じ 1.5.0 で、範囲が対応するプレリリースタグを運ぶため）。一方、平易な ^1.5.0 は 1.5.0-rc.1 を通しません — このゲートはまさに、あなたがオプトインするまでリリース候補をリリースの依存関係解決から遠ざけるために存在します。

よくある質問#

1.0.0 は 1.0.0-beta より高いですか？#

はい。プレリリースタグのないバージョンは、同じ major.minor.patch でも、タグのあるバージョンより常に高い優先度を持ちます。だから 1.0.0 > 1.0.0-rc.1 > 1.0.0-beta.11 > 1.0.0-alpha。これが、リリースが「ゴールデンになる」ことが単なるラベル変更ではなく実際の優先度上昇である理由です。

^ と ~ の違いは何ですか？#

キャレットは左端の非ゼロ構成要素を変更しない更新を許可します: ^1.2.3 は 1.2.3 から 2.0.0 未満までの任意の 1.x.x を許可します。チルダはより厳しく — 完全なバージョンを与えられたときはマイナーを固定します: ~1.2.3 は 1.2.x のみを許可します。マイナーだけ（~1）を与えられたとき、チルダとキャレットは両方ともマイナー全体の範囲を許可します。ほとんどのライブラリは ^ で固定し、自分が公開したパッケージへのパッチはしばしば ~ を使います。

なぜ私のプレリリースバージョンは ^1.0.0 を満たさないのですか？#

設計通りです。1.5.0-rc.1 のようなプレリリースは、同じ AND セット内の比較子が同じ 1.5.0 にプレリリースタグを持つときだけ範囲を満たします。^1.0.0 は 1.5.0 にプレリリースなしの >=1.0.0 <2.0.0-0 に脱糖されるため、ゲートはあなたのリリースビルドが誰かのランダムなリリース候補を引っ張るのを防ぎます。オプトインしたいなら、明示的に ^1.5.0-rc.0 と書いてください。

ビルドメタデータは比較に影響しますか？#

いいえ。1.0.0+exp.sha.5 と 1.0.0+exp.sha.6 は同じ優先度です — ビルドメタデータは識別のみに使われます。パーサーはそれを表示し（メタデータだけが異なるとき diff は build 変更を報告します）が、順序付けを決することはありません。