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

この記事は最終更新日から 6年以上 が経過しています。

最近のアプリケーションは開発効率を上げるために大量のライブラリを組み合わせて作成することが多くなっています。 そういった状況下では、たった1つのライブラリがバージョンアップすることで、そのライブラリに依存している他のライブラリが正常に動作しなくなり、 やがてアプリケーション全体が正常に動作しなくなるというような状況に陥ります。

あるライブラリが別のライブラリに依存しており、さらにそのライブラリはまた別のライブラリに依存している…というような状況(依存性地獄:Dependency hell)を人間の手で管理していくのはほぼ不可能です。

npm、yarn、bower などのパッケージ管理システム(パッケージマネージャー)はこの依存関係を自動的に解消してくれますが、 それを可能にしているのは規則正しいバージョン番号付けによるものです。

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

セマンティック バージョニング(Semantic Versioning)とは、バージョン番号のつけ方に関する規約です。 いままでは各アプリケーションでバラバラなルールをもとにつけられていたバージョン番号でしたが、バージョン番号のつけ方に明確に意味を持たせ統一的なルールで番号をつけることによって、システム的に扱いやすくしようというものです。 省略して semver と呼びます。

このセマンティック バージョニングに従ってバージョン番号をつけることによって、 新しいバージョンに上げてしまうとアプリケーションが動かなくなってしまうのか、それとも動作に影響がないのか、 バージョン番号からある程度判断することができるようになります。

バージョン番号のつけ方

通常のバージョン番号は、「メジャーバージョン.マイナーバージョン.パッチバージョン」というように3つの数字を.で繋いだ形式にしなければなりません。 それぞれの番号は 0 から始め、負の整数であってはいけません。 また、各番号の先頭にゼロを置いてはいけません(誤:1.02.3、正:1.2.3)。 各バージョンの番号は数値的に上がっていきます(例:1.9.0 → 1.10.0 → 1.11.0)。 上位の番号が上がると下位の番号は 0 にリセットします(例:1.23.45 → 1.24.0、1.23.45 → 2.0.0)。

semver.png

メジャーバージョン

バージョン番号の1つ目はメジャーバージョンを表します。 APIやI/Fを変更して後方互換性がなくなるような変更を行った場合は、この番号を上げなければなりません。 つまり、この番号が変わってしまった場合、これを使っているアプリケーションは個別に対応しないと動作しなくなる可能性があります

メジャーバージョンが 0 の場合(0.y.z)は、初期段階の開発用です。

マイナーバージョン

バージョン番号の2つ目はマイナーバージョンを表します。 後方互換性を保ちつつ、機能を追加した場合は、この番号を上げなければなりません。 マイナーバージョンまでであれば、特に気にせずにバージョンを上げてしまっても動作に影響はしないはずです

npm における ^x.y.z 表記は、マイナーバージョンまでの更新なら許可するという指定です。

パッチバージョン

バージョン番号の3つ目はパッチバージョンを表します。 後方互換性を保ったバグ修正を取り込んだ場合のみ、この番号を上げます。 基本的にバグ修正なので、気軽にバージョンを上げてしまっても動作に影響しないはずです。

npm における ~x.y.z 表記は、パッチバージョンの更新なら許可するという指定です。

プレリリースバージョン

リリースする際、α版、β版、RC版などのように特別なバージョンとして扱いたい場合があります。 その場合は、バージョン番号の直後に - と . で区切られた識別子を追加することができます。 識別子は必ず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

同じ、メジャー、マイナー、パッチを持つプレリリースバージョンの優先度は、数値のみで構成される識別子は数値的に比較され、文字列やハイフンを含む識別子はASCIIソート順に辞書的に比較されます。

例:1.0.0-alpha < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0

ビルドメタデータ

例えば、CIなどで自動ビルドが走っている場合などに、ビルド番号をバージョン番号に付与したいと思うことがあるかもしれません。 その場合は、パッチバージョンもしくはプレリリースバージョンの直後に + と . で区切られた識別子を追加することができます。 識別子は必ずASCII英数字とハイフン[0-9A-Za-z-]で指定し、空であってはなりません。 バージョンの優先度を決める際にはビルドメタデータは無視されます。

例:1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85

補足

開発フェーズでのバージョン番号のつけ方

開発フェーズでは、メジャーバージョンを 0 として、0.y.z のような番号をつけます。 最初のバージョン番号は 0.1.0 から始め、その後のリリースのたびにマイナーバージョンを上げていきます。 初公開時にはバージョン番号を 1.0.0 としてリリースしましょう。

リリース後のコンテンツの修正はしてはいけない

一度リリースしたのなら、そのバージョンのコンテンツは修正してはなりません。 いかなる修正も新しいバージョンとしてリリースしなければなりません。

まとめ

バージョン番号をつけるときは、セマンティック バージョニングに従いましょう。

参考サイト

関連記事

最近の Web 界隈では、UX を高めるために、UI を JavaScript でガリガリ実装するというのが普通になってます。フロントエンドエンジニアなんていう職種が生まれるほど、この界隈は活発です。そこでフロントエンド開発でほぼ必須となるであろう Node.js と npm について少しまとめてみます。今更感がすごい ...
もはや PHP で開発を行う際に、使用していないプロジェクトは探すのが大変なぐらいスタンダードな存在となった Composer ですが、昨年めでたく 2.0 になったということで、改めて少しまとめてみます。今更とか言っちゃダメです。Composer とは?Composer は、PHP の依存関係管理のためのツールです。 ...

記事検索

最新記事

人気記事

RSSフィード

お知らせ

フィードバック

要望などあれば、お気軽にどーぞ。 不具合やバグを発見した場合も、連絡をいただけると助かります。

匿名でフィードバックする
匿名でフィードバックする

要望などあれば、お気軽にどーぞ。 不具合やバグを発見した場合も、連絡をいただけると助かります。

なお、このフォームから入力された内容について、管理者から返信はできませんので注意してください。 もし、管理者からの返信が必要であれば、X(Twitter) もしくは、お問い合わせより、お願いします。

  • フィードバックの送信が完了しました。