semver

セマンティック バージョニング（SemVer 2.0.0）

SemVer 2.0.0 の判定ロジックとリファレンスです。バージョンの更新内容と理由だけが必要な他のワークフロー（keep-a-changelog と conventional-commits のスキルなど）でよく使われるため、回答は簡潔にしてください。

バージョンは、宣言されたパブリック API に関する互換性の約束です。MAJOR は互換性を破壊する変更、MINOR は互換性を保った新機能、PATCH は互換性を保った修正です。宣言されたパブリック API がなければ、「破壊的変更」の定義はありません。判定の前に API を確立するか、確認してください。

形式

MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD]

• MAJOR.MINOR.PATCH：先頭にゼロを付けない、0 以上の整数です（1.9.0）。
• - の後にプレリリースを記述します（1.0.0-alpha.1）。+ の後にビルドメタデータを記述します（1.0.0+20130313144700）。
• プレリリース／ビルド識別子には [0-9A-Za-z-] を使用し、ドットで区切ります。空にすることはできません。数値のプレリリース識別子には先頭にゼロを付けません。

更新レベルの決定

「新しいもの＝MINOR」とパターンで決めないでください。次の 3 ステップで判断します。

1. パブリック API を特定します。 バージョンが意味を持つのは、利用者が依存する公開範囲が宣言されている場合に限ります。ライブラリのエクスポート、CLI のフラグ、HTTP コントラクト、リポジトリ内でインストール可能なスキルの集合などが該当します。公開範囲が宣言されていない場合は、確立するか確認してください。そうしなければ「破壊的変更」の定義はありません。
2. 変更の規模ではなく、公開範囲に対する影響で各変更を分類します。 既存の使い方を 壊す のか、互換性のある機能を 追加する のか、既存のコントラクトの範囲内で動作を 修正する のかを確認します。まったく新しく、オプトインで利用する単位、たとえば新しいスキルやサブコマンドの追加は、追加的な変更であり、破壊的変更ではありません。既存の使い方に変化がないためです。
3. 該当するレベルを選びます。メジャーゼロの扱いに注意してください。 それぞれの数字が何を約束するかは、1.0.0 をリリースしているかどうかで異なります。

1.0.0 以上の場合 — パブリック API は約束です。最初に該当した項目を選びます。

1. 下位互換性のない変更がある → MAJOR（MINOR と PATCH を 0 にリセット）。
2. 下位互換性のある新機能、または非推奨化 → MINOR（PATCH を 0 にリセット）。
3. 下位互換性のある修正のみ → PATCH。

0.y.z の場合 — 初期開発段階で、1.0.0 はまだリリースされていないため、約束はありません。数字は代わりに 相対的な リスクを示します。^ の範囲指定の解決方法に合わせて、尺度が 1 つ下のレベルにずれます（^0.1.0 は >=0.1.0 <0.2.0 を意味するため、MINOR が破壊的変更を示す位置になります）。

1. 下位互換性のない変更 → MINOR（0.3.2 → 0.4.0。PATCH を 0 にリセット）。
2. 互換性のある変更 — 機能追加 または 修正 → PATCH（0.3.2 → 0.3.3）。

そのため、0.1.0 のリポジトリに新しいスキルを追加する場合は、MINOR ではなく PATCH として 0.1.1 にします。0.x バージョンには安定性の保証がないことを必ず明示し、API が安定して本番環境で使われるようになったら 1.0.0 をリリースしてください。

変更が混在する場合：リリースレベルは最も影響の大きい変更で決まります。破壊的変更が 1 つでもあれば、そのレベルになります。

バージョン文字列の検証

公式の正規表現：

^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

グループ：1＝メジャー、2＝マイナー、3＝パッチ、4＝プレリリース、5＝ビルド。次の場合は指摘してください。先頭にゼロがある（01.2.3）、先頭に v がある（v1.2.3 — タグの接頭辞なので、検証前に削除）、コンポーネントが 3 つ未満（1.2）、プレリリース／ビルド識別子が空（1.0.0-）。

優先順位の比較

1. MAJOR、MINOR、PATCH の順に数値で比較します。最初に異なる値で決まります。
2. コア部分が同じ場合、プレリリースがあるバージョンは、ないバージョンよりも低くなります（1.0.0-alpha < 1.0.0）。
3. どちらにもプレリリースがある場合、識別子を左から順に比較します。両方が数値なら数値で比較し、それ以外は ASCII 順で比較します。数値は英数字より低くなります。共通部分の識別子がすべて同じ場合は、識別子の多い方が上位です。
4. ビルドメタデータは優先順位に影響しません。

低い順：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0

エッジケース

• **マイナー／パッチバージョンで破壊的変更をリリースしてしまった場合：**公開済みのバージョンは変更せず、互換性を回復するパッチをリリースしてから、MAJOR で正しく破壊的変更を行います。
• **依存関係の更新のみの場合：**バグを修正するなら PATCH、新機能を公開できるようになるなら MINOR にします。
• **非推奨にする場合：**MINOR を上げて、その旨を文書化し、MAJOR で削除するまで少なくとももう 1 回のマイナーリリースの間は維持します。
• リリース済みバージョンは不変です — 修正は新しいバージョンとしてリリースします。
• **0.0.z：**メジャーゼロの変更では互換性のある範囲がないため（^0.0.3 が許可するバージョンはありません）、すべての変更が破壊的になり得るものとして扱い、PATCH を上げて、不安定であることの警告を残します。

別のワークフロー向けの簡潔な出力

current: 0.3.2
bump: patch
next: 0.3.3
reason: added an opt-in --dry-run flag; no existing behaviour changes
warning: pre-1.0 (0.y.z) — no compatibility promise; minor is the breaking slot

入力バージョンが無効な場合、または 0.y.z の場合にのみ warning: 行を追加します。ここで扱っていない内容（BNF 文法、FAQ 全文）については、semver.org を参照してください。