セマンティックバージョニングとは

3年以上前に更新されました。情報が古い可能性があります。
更新日 : 2020年02月19日

セマンティックバージョニングという、プロジェクトやライブラリをリリースする際のバージョン指定に関するルールを決めたものがあります。

今回はこのセマンティックバージョニングについて解説します。

セマンティックバージョニングの必要性

自分たちのプロジェクトで使用しているライブラリのバージョンがアップデートされると、自分たちのプロジェクトに影響を与える可能性があります。
逆にバージョンを固定化してしまうと、自分たちのプロジェクトで使用しているライブラリのバージョンを更新できなくなり、セキュリティリスクを抱える可能性もあります。

上記のようなリスクを抑えるため、セマンティックバージョニングというバージョン指定をする際のルールが存在します。

これを採用しているComposerなどを利用する際に、このセマンティックバージョニングを知っていれば自分たちのプロジェクトのリスクを抑えることが可能になります。

ただしあくまでもルールであり仕様なので、セマンティックバージョニングを採用していると言っても、その通りにリリースされないライブラリなどがまれにあるので注意が必要です。

バージョニングの基本

セマンティックバージョニングはバージョンの指定方法やバージョンの上げ方についてのルールです。

まずはバージョン情報がどのような構成になっているか確認し、基本を抑えましょう。

バージョンの決定方法

バージョニングはX.Y.Zのように決めます。それぞれxyzの部分には数字が入ります。それぞれの意味は以下の通りです。

X: メジャーバージョン
大規模な変更が起き、今までの過去のバージョンとの互換性が失われるときにメジャーバージョンの数字をあげます。
Y: マイナーバージョン
過去のバージョンとの互換性は失われませんが、新規機能の開発や機能改善が行われたときにマイナーバージョンの数字をあげます。自分たちのプロジェクトの影響を最小限に抑えつつきちんとアップデートするのであればマイナーバージョンは上げましょう。
Z: パッチバージョン
主にバグ修正のためのバージョン情報です。バグ修正が行われたときにパッチバージョンの数字をあげます。自分たちのプロジェクトで扱う際には必ずこのバージョンは上げたほうがいいです。

基本的にはこれだけです。そしてこれらの数字は、時系列上必ず大きくしなければいけません。

ここまでが自分たちのプロジェクトで使用するライブラリ(依存するライブラリ)で考えるべきセマンティックバージョニングの解説です。

次にライブラリを作成する場合に理解しておきたいセマンティックバージョニングの仕様について説明します。ライブラリを作成する側でない場合には、以下の内容を理解する必要はありません。

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

セマンティックバージョニングのバージョンの上げ方やルールには仕様が決まっています。
もし仮にライブラリを作成したり、ライブラリのオープンソースプロジェクトに参画する場合には以下の内容を把握しておきましょう。

仕様を説明するにあたりいくつかの表現が使われているので、その表現ごとにまとめて説明します。

バージョニング設定時に必ずしなければいけないこと(MUST)

バージョニングを設定する際に必ず従わないといけないルールは以下のとおりです。

パブリックAPIを宣言しなければならない
これは外部から利用されるライブラリであれば当たり前ですが、パブリックAPIを宣言し、外部プログラムから利用されるAPIを作成する必要があるということです。
通常のバージョンはX.Y.Zの形式、かつそれぞれの数字が非負の整数でなくてはならない
非負の整数というのは0以上の整数でなければならないということです。
バージョン番号は各数値の先頭にゼロを配置してはいけない
01.05.09のようにしてはいけません。左のバージョンは正しくは1.5.9です。ただし1.0.5のようにバージョン番号自体がゼロの場合はOKです。
各バージョンは数値的にバージョンアップしなければならない
バージョンダウンはだめということですね。
一度リリースされたバージョンに対して修正してはいけない、いかなる修正もバージョンアップとして対応する
パッチバージョン(X.Y.ZのZ)は後方互換性を保ったバグ修正を取り込んだ場合のみ上げなければならない
今までのパブリックAPIと仕様が変わらず、バグ修正を行った場合はパッチバージョンを上げます。
マイナーバージョン(X.Y.ZのY)は後方互換性を保ちつつ機能性をパブリックAPIに追加した場合上げなければならない
今までのパブリックAPIを残しつつ、新規でパブリックAPIを追加した場合などにはマイナーバージョンを上げます。
メジャーバージョン(X.Y.ZのX) はパブリックAPIに対して後方互換性を持たない変更が取り込まれた場合上げなければならない
既存のパブリックAPIの仕様と異なる場合にはメジャーバージョンを上げます。
メジャーバージョンを上げた場合にはマイナー・パッチバージョンをどちらも0にリセットしなければならない
もしプレリリースバージョンを表現したい場合には、パッチバージョンの直後にハイフンとドットで区切られた識別子を追加することで表現してもよく、識別子は必ずASCII英数字とハイフン0-9A-Za-z- でなければならない、また識別子は空であっていけない、数値の識別子はゼロから始めてはいけない
プレリリースバージョンをつけない場合には関係ありませんが、付ける場合には上記のようなルールになります。例:1.0.0-alpha・1.0.0-alpha.1・1.0.0-0.3.7・1.0.0-x.7.z.92

これらのルールの他に、ビルドメタデータについてのルールもありますが、ビルドメタデータをつけたバージョンをつけるライブラリは多くないため説明を省略します。

これらのルールがMUSTとして決められています。しっかり読めば、当たり前の内容がほとんどです。メジャー・マイナー・パッチバージョンを上げる際のルールと、プレリリースバージョンの決められた文字だけ注意しましょう。

バージョニング設定時にしてもよいこと(MAY)

バージョニング設定時にしても良いことは以下のとおりです。

マイナーバージョンはプライベートコード内での新しい機能の追加や改善を取り込んだ場合は上げてもよい、そのときにパッチレベルの変更を含めてもよい
プライベートなコード(privateと書いてあるメソッドや機能などの内部コード)の改善や機能追加の場合にはマイナーバージョンを上げます。そのときにパッチレベルの変更(バグ修正)も含めて大丈夫です。
メジャーバージョンを上げる場合、マイナーおよびパッチレベルの変更も含めてもよい

以上が行っても問題ないバージョニング設定です。ビルドメタデータの説明は除外しています。

まとめ

以上がセマンティックバージョニングの解説になります。ライブラリを利用するだけの開発者はメジャー・マイナー・パッチバージョンのそれぞれの違いと特徴を捉えておけば問題ありません。

ライブラリの開発者はバージョニング設定時のルールまで把握しておくと利用者ごとのライブラリの影響を最小限に抑えることができます。

今回の内容はセマンティックバージョニング公式サイトに従って記載しています。詳しい内容は日本語版を読めば理解できるかと思います。公式サイトには簡単なQ&Aも記載されています。