SemVer（セマンティックバージョニング）：Dev Basics／Keyword
SemVerとはソフトウェアのバージョン番号の付け方に一貫した意味付けを与えることで、その後方互換性情報が一目で分かるようにしたものだ。
SemVer（日本語訳）とは、ソフトウェアのバージョン番号の付け方に一貫した意味付けを与えたもの。
SemVerにおけるバージョン番号の意味
SemVer（Semantic Versioning： セマンティックバージョニング）では、何らかのパブリックなAPIに関して通常のバージョン番号は「X.Y.Z」形式とするものとしている（ここでいう「パブリックなAPI」とは何らかのソフトウェアパッケージやライブラリ、アプリなど、外部に対して何らかの機能を提供するものと考えられる。また、パブリックなAPIはドキュメントによって規定されることも、プログラムコード自体によって強制されることもある）。そして、「X.Y.Z」には以下のような意味が付与されている。なお、「X」「Y」「Z」には非負の整数値を使用し、先頭に0を前置してはいけない（01.0.0などとしてはいけない）。
- X： メジャーバージョン
- Y： マイナーバージョン
- Z： パッチバージョン
メジャーバージョン（X）が0である間は（バージョンが「0.Y.Z」である間）、そのソフトウェアは開発初期段階にあり、パブリックなAPIは安定的なものではない（パブリックなAPIは「宣言」された状態）。そのため、どのような破壊的変更が行われるかは分からない。
バージョン「1.0.0」のリリース時にパブリックなAPIが「定義」される。これにより、そのAPIは安定的なものとなる。SemVerでは、バージョン1.0.0以降の変更では、以前のバージョンに対する後方互換性が維持されているかどうかが簡単に分かるように、メジャー／マイナー／パッチの各バージョン番号の付け方が決められている。こうすることで、自分が使っているフレームワークやライブラリのバージョンアップ時にバージョン番号を参照することで、「後方互換性があるので安心して使える」かどうかがすぐに分かるようになっている。
バージョン1.0.0リリース後の各バージョン番号の付け方はおおよそ次のようになっている。
- メジャーバージョン： 以前のバージョンに対する後方互換性がないAPIの変更があった場合にはメジャーバージョンを上げ「なければいけない」。このとき、マイナー／パッチバージョンは「0」に戻る（例：1.9.1→2.0.0）
- マイナーバージョン： 以前のバージョンに対する後方互換性を維持しつつ、新たな機能をパブリックAPIに追加した場合にはマイナーバージョンを上げ「なければいけない」。このとき、パッチバージョンは「0」に戻る
- パッチバージョン： 以前のバージョンに対する後方互換性を維持したまま、バグ修正を行った場合には、パッチバージョンを上げ「なければいけない」
メジャーバージョンアップ時にはマイナー／パッチレベルの変更を（バージョン2.0.0リリース時に新機能の追加や各種のバグフィックスを含めるなど）、マイナーバージョンアップ時にはパッチレベルの変更を含めてもよい。
また、パブリックなAPIに変更がないまま、ソフトウェア内部で大きな変更があった場合にはマイナーバージョンを上げ「てもよい」（リファクタリングによる性能改善が行われた場合などが当てはまるだろう）。さらに、特定のAPIを廃止予定としたタイミングでマイナーバージョンを上げ「なければいけない」。
「X.Y.Z」に続けて「プレリリースバージョン」や「ビルドメタデータ」を付加してもよい。プレリリースバージョンとは「alpha」「beta」など、よく見る識別子（とそこに付加される数字列など）のこと。プレリリースバージョンはパッチ番号の後にハイフンを続け、その後に英数字とハイフンで構成される識別子をドットで区切って記述する。例えば、「1.0.0-alpha.99」など。プレリリースバージョンは後方互換性を適切に維持できていない場合もあることを意味する。
ビルドメタデータも英数字とハイフンで構成される識別子をドット区切りで記述するが、こちらは「パッチバージョン」か「プレリリースバージョン」直後の「+」に続ける。例えば、「1.1.1-alpha+20161206050000」や「1.1.1+nightly」がそうだ。
SemVerでは、各バージョンを比較するための「優先度」も規定されている。詳細は割愛するが、メジャー／マイナー／パッチ／プレリリースの各バージョン番号が数値として、または辞書式順序で比較され、優先度が決定する。ビルドメタデータは優先度の計算には用いられない（よって、メジャー／マイナー／パッチ／プレリリースが同一で、ビルドメタデータが異なる2つのバージョンは同一の優先度になる）。詳細な仕様については「Semantic Versioning 2.0.0」を参照してほしい。
SemVerは多くのソフトウェアで使われるようになっている。例えば、.NET CoreではSemVerを使用してバージョン管理を行うと述べられている。あるいは、Node.jsアプリ開発でパッケージを管理するために使われるpackage.jsonファイルでも、必須フィールドの1つであるversionフィールドはSemVerに沿ったものとして記述する必要がある。実際には、Node.js用のパッケージnode-semverがversionフィールドのパースには使われ、node-semverではSemVerに沿ったバージョンの範囲を簡潔に記述できるような構文が規定されている。
SemVerがなぜ必要か
上述してきたように、SemVerは後方互換性情報をバージョン番号を見るだけで、ある程度判断できるようにするための仕組みだ。つまり、自分が依存しているソフトウェアのバージョンアップ時にその互換性情報が即座に分かるようになっている。
「X.Y.Z」という形式のバージョン番号はよく見るが、その意味するところがソフトウェアごとに異なることはよくある。例えば、自分が使っているフレームワークのバージョンが2.0から2.1に上がったときに、互換性が維持されているかどうかは不明だ。
マイナーバージョンアップなので互換性が維持されていると期待はできる。だが、マイナーバージョンアップ時に同時に行われたただ1つの破壊的な変更が原因となって、新バージョンを使うには自分たちのソースコードにも変更が必要になるかもしれない。そうではなく、互換性が維持されていて、問題なくそのフレームワークを使い続けられるかもしれない。バージョン番号の付け方がソフトウェアごとにバラバラだと、バージョンアップしたソフトウェアに互換性があるかどうかはリリースノートに目を通したり、実地にテストをしたりしなければ分からないかもしれない。
そこでバージョン番号の付け方に関して、メジャー／マイナー／パッチ／プレリリース／ビルドメタデータなどの用語とその意味を定義することで、その定義に従っている限りは例えば「マイナーバージョンアップなのでこのフレームワークを使い続けられる」「メジャーバージョンが上がったからちゃんと動くかテストが必要だ」といった判断を簡単に行えるようにするのがSemVerが目指すところだ。
SemVerは、「X.Y.Z」形式のバージョン番号の付け方に一貫した意味付けを与え、パッケージの後方互換性に関する情報を簡単に判断できるように仕組みだ。多くのソフトウェアで採用されるようになってきていることからも、知っておくと（また使うようにすると）よいだろう。詳細については以下のリンクを参考にされたい。
Copyright© Digital Advantage Corp. All Rights Reserved.