この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
CX 事業本部では Node.js を使うことが増えてきました。ここで前提の整理として一度 Semantic Versioning についてまとめます。
Semantic Versioning は SemVer と略します。本記事内では以降、 SemVer で表記を統一します。
ちなみに SemVer の読み方はカタカナで強引に書くと、「センバー」になります。発音記号としては sémbɚ です。 member の先頭を s で発音する、と覚えると良いでしょう。
TL;DR
- 基本的に数字 3 つでバージョンを表し、リリース前の不安定なバージョンには
alphaやrcなどがつくことがある - 一番左の数字が大きくなったら後方互換性がない
- 一番左の数字が 0 のときはどの数字が上がっても後方互換性がない
- たまに一番左以外の数字があがったときに後方互換性がない場合がある
リルオッサが図解してくれました。多分これが一番わかりやすいと思います
Semantic Versioning とは
Tom Preston-Werner によって定義されたソフトウェアにバージョンを振るための 1 手法です。
すべての仕様は次のサイトにまとまっています。
日本語版もあるのですが、翻訳されていない箇所があるので参考程度に参照してください。
基本
3 つの数字を U+002E つまり . でつないだものが基本形です。たとえば 3.14.1 などですね。
各数字は 0 そのものを除き、桁合わせのために先頭に 0 をつけてはいけません。 03.14.01 は SemVer として誤りです。
一番左側の数字をメジャーバージョン、真ん中の数字をマイナーバージョン、一番右側の数字をパッチバージョンと呼びます。
パッチバージョン
後方互換性のあるバグ修正やドキュメントの変更などをした場合、パッチバージョンの値をひとつ大きくします。
マイナーバージョン
後方互換性のある機能追加とドキュメントの追記をした場合、マイナーバージョンの値をひとつ大きくします。
また、廃止予定のインターフェイスがある場合、ドキュメントにその旨を追記し、マイナーバージョンをひとつ大きくします。実際に廃止する際は後述するメジャーバージョンをひとつ大きくします。
マイナーバージョンの値が大きくなるときにパッチバージョンの値を 0 とします。
メジャーバージョン
後方互換性のない変更がある場合、メジャーバージョンの値をひとつ大きくします。
メジャーバージョンの値が大きくなるときにマイナーバージョンとパッチバージョンの値を 0 とします。
注意点
初期開発バージョン
メジャーバージョンが 0 の場合は初期開発段階を示します。そのため、マイナーバージョンとパッチバージョンのどちらが上がっても後方互換性を保つ必要はありません。
プレリリースバージョン
メジャーバージョンが 1 以降の場合、後方互換性を保てるか不明な場合はプレリリースバージョンを使用しましょう。
プレリリースバージョンはパッチバージョンの後ろに U+002D をつなげ、その後に続く部分です。アルファベットと数字を . 区切りで記載可能です。
例としては 3.14.1-rc や 1.3.10-beta.2 などです。 rc は release candidate の略で、リリース前の最終確認バージョンです。
接頭辞はつけないように
v1.3.10 のように先頭に v をつけるのは SemVer として誤りです。 Git を用いた開発などで tag を打つ際、 git tag v1.3.10 と打つのは構いませんが、プログラムの解析対象などに対して v を接頭辞として用いるのはやめましょう。
後方互換性の維持は難しい
SemVer を採用したパッケージを使用する際、メジャーバージョンが上がっていないからといって後方互換性が保たれているとは限りません。というのも、後方互換性の維持は非常に難しいことだからです。ある機能追加がその他の機能を阻害するということもあり得ます。
使用する側からすると厳密に従ってほしい気持ちはありますが、あくまで指針ですので盲目的に信頼しすぎないようにしましょう。アップグレード後に軽くテストするなどの対応をとりましょう。
まとめ
自分で作成する際はもちろん、 SemVer を採用したパッケージを使う際は後方互換性の有無に気をつけましょう。