Semantic Versioning

  • 16
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

Semantic Versioning って何?

Semantic Versioning とは、バージョン番号の付け方のルールのことです。

なぜ必要か?

バージョン番号の大小を、プログラムで機械的に判定したい、というのが動機です。このために厳密な仕様が定義されています。

どこで使われているか?

パッケージを管理するシステムで使われています。RubyGems や CocoaPods がそうです。

備考:一般のアプリの場合

Semantic Versioning は、主として、ライブラリ向けのバージョン番号を想定しています。

一般のアプリは必ずしも Semantic Versioning を守る必要はありません。しかし、バージョン番号の付け方に迷うようなら参考にしてもよいかと思います。

なお、バージョン判定をする何らかのフレームワークを使うなら、その動作仕様を知っておくべきです。例えば、OS X アプリの自動更新機能を提供する Sparkle では、Semantic Versioning とは微妙に違うルールでバージョン判定されます。

仕様の基本事項

バージョン番号の形式

Major番号.Minor番号.Patch番号」と、3つの数字をドットでつないだ番号となります。常に3つの数字を使い、省略はできません。

例:1.0.0 2.1.3 3.10.1

番号の意味

  • Patch番号:バグ修正の時にインクリメントする番号です。
  • Minor番号:後方互換性がある変更の時にインクリメントする番号です。
  • Major番号:後方互換性がない変更の時にインクリメントする番号です。

なぜ番号の意味が決まっているかというと、アプリがライブラリを使う場合にどういった範囲の更新を許容するかを指定したいからです。以下のような指定が可能になります。

  • バグ修正(Patch)は許容するが、機能追加(Minor)は許容しない。
  • 機能追加(Minor)は許容するが、従来機能の変更(Major)は許容しない。

補足:開発段階

Major 番号が 0 のものは、開発段階を示します。この場合は、Minor 番号や Patch 番号に上記のような番号のルールはありません。API の仕様も確定していない状態であり、API に非互換な変更がされることも十分ありえます。

Major 番号が 1 以上になった時点で、Public な API が公開された、という扱いになります。その後、上記の番号のルールに従います。

応用(1) プレリリース

ベータ版や RC 版のバージョン番号の付け方です。

バージョン番号の形式

X.Y.Z-hoge」と、通常バージョンの後にハイフンをつけて、プレリリース文字列を追加します。

大小判定

プレリリースは、通常バージョンより低いバージョンとなります。

例:1.0.0 < 1.1.0-alpha < 1.1.0

通常バージョン部分が同じプレリリース同士では、プレリリース文字列の ASCII ソート順になります。

例:1.1.0-alpha < 1.1.0-beta < 1.1.0-beta2 < 1.1.0-RC

応用(2) ビルドメタデータ

バージョン番号の形式

X.Y.Z+fuga」と、通常バージョンの後にプラスをつけて、ビルドメタデータ文字列を追加します。

あるいは、「X.Y.Z-hoge+fuga」と、プレリリースバージョンの後にプラスをつけて、ビルドメタデータ文字列を追加します。

大小判定

ビルドメタデータは、バージョンの大小に影響を与えません。

例:1.1.0 = 1.1.0+ext1 = 1.1.0+ext2

例2:1.1.0-alpha = 1.1.0-alpha+ext1 = 1.1.0-alpha+ext2

参照

仕様書:Semantic Versioning 2.0.0

この記事はLTで発表した内容を整理したものです。LT発表資料:Semantic Versioning // Speaker Deck