セマンティックバージョニング

セマンティックバージョニングとは

セマンティックバージョニング(SemVer)は、ソフトウェアのバージョン番号を メジャー.マイナー.パッチ(例: 2.4.1)の3つの数字で表し、番号自体に変更の意味を持たせるルールです。

利用者は番号を見るだけで「上げても安全か」を判断できます。パッチとマイナーは基本的に安全、メジャーが上がったら移行作業が必要かもしれない、と読み取れるわけです。

パッケージ管理との関係

SemVer が最も活躍するのは依存パッケージの管理です。[[npmとパッケージ管理]] では、package.json に範囲指定でバージョンを書きます。

{
  "dependencies": {
    "express": "^4.18.0",
    "lodash": "~4.17.21"
  }
}

• ^4.18.0 — メジャーを固定し、マイナー・パッチの更新を許可(4.x.x の最新)
• ~4.17.21 — マイナーまで固定し、パッチの更新のみ許可(4.17.x の最新)

この仕組みは「作者が SemVer を守っている」という信頼の上に成り立っています。だからこそ、自分がライブラリを公開する側になったら SemVer を守ることが重要です。

初学者向けポイント

• 1.0.0 未満(0.x.x)は「開発中で何が変わってもおかしくない」段階を意味します。0.x のライブラリは破壊的変更に注意しましょう
• 破壊的変更かどうかは「利用者のコードが修正なしで動き続けるか」で判断します。関数の削除や引数の変更はメジャー、追加はマイナーです
• リリース時には [[Git]] のタグ(v2.4.1 など)でバージョンとコミットを紐付けるのが定番です
• Web API のバージョン管理([[APIバージョニング]])でも「破壊的変更でバージョンを上げる」という同じ考え方が使われます

関連技術とのつながり

• [[npmとパッケージ管理]] — ^ や ~ の範囲指定は SemVer が前提
• [[APIバージョニング]] — 破壊的変更の管理という同じ課題を Web API で扱う
• [[OSSとライセンス]] — 公開ライブラリの運用ではバージョン規約とライセンスが利用者との約束になる
• [[Git]] — タグでバージョンとコミットを紐付ける

Q: バージョン 2.4.1 の「2」を上げるのはどんなとき?
- [x] 互換性が壊れる変更(破壊的変更)をしたとき
- [ ] バグを修正したとき
- [ ] 後方互換のまま機能を追加したとき
解説: 1つ目の数字はメジャーバージョンで、破壊的変更のときに上げます。機能追加はマイナー、バグ修正はパッチです。

Q: package.json の `^4.18.0` という指定が許可する更新はどれ?
- [ ] 5.0.0 への更新
- [x] 4.x.x の範囲でのマイナー・パッチ更新
- [ ] 一切の更新を許可しない
解説: `^` はメジャーバージョンを固定し、その範囲内のマイナー・パッチ更新を許可します。

Q: バージョン 0.x.x のライブラリについて本文が述べているのはどれ?
- [ ] 最も安定した完成版であることを示す
- [ ] 商用利用が禁止されていることを示す
- [x] 開発中で破壊的変更が起こりうる段階を示す
解説: 1.0.0 未満は開発中の段階を意味し、どのリリースでも互換性が変わる可能性があるため注意が必要です。