OSS 界隈ではメジャーっぽいのですがセマンティック・バージョニングという必殺技っぽい名前の、バージョン番号付けのガイドラインがあるみたいです。 人間が判別しやすくなるという理由もありますが、プログラム側から判別できるようになり、RubyGems や CocoaPods 、 NPM などでもこのルールで更新されています。

セマンティック・バージョニング 日本語 に詳しく書かれています。

これを要約すると：ルールはシンプル。

1. X.Y.Z (メジャー.マイナー.パッチ) の形式で定義するぞい。
2. 正の整数で定義するぞい。(ex. 1.9.0, 3.2.12, 6.0.198)
3. 0.Y.Z の時は、開発用じゃ。公開したら 1.0.0 にするぞい。
4. 修正を同じバージョンで適用してはいけないぞい。
5. Z (パッチ) は主にバグ修正時に上げるぞい。
6. Y (マイナー) は後方互換を保ったまま機能追加した場合に上げるぞい。また、X (メジャー) で予定する機能削除を告知する場合も上げるぞい。
7. X (メジャー) は後方互換がない変更を行った場合に上げるぞい。
8. Y (マイナー) を更新した場合は Z (パッチ) を、X (メジャー) の場合は Y (マイナー), Z (パッチ) をそれぞれ思い切って 0 にリセットじゃ。

また、プレリリースバージョン (ex. 1.0.0-alpha) や、ビルドメタデータ (1.0.0+20151212235959, 1.0.0-alpha+exp.sha.4e2a30b) なども定められています。 npm / rubygem / cocoapod とかでライブラリを公開している場合、セマンティック・バージョニングを気にするといいみたいです。

ルールをリフレインすると：

1. API が変更され、バージョンアップしてしまうと手元のコードに変更が必要になる場合は X (メジャー) を上げるぞい。
2. 機能を追加したり、deprecated (非推奨) にする API がある場合は Y (マイナー) を上げるぞい。
3. 機能は追加されないけどバグ修正を行った場合は Z (パッチ) を上げるぞい。

API の名前を変えたいなーと思ったら、前バージョンの API は残しつつ deprecated 宣言を行い、新 API を追加し、Y (マイナー) だけを上げるのが良い、ということになります。

セマンティック・バージョニングは主にプラグラムのライブラリ向けに定義されています。

一般的なアプリのバージョンは商業的な意味合いが強くなるのでこれを適用する必要はないとされています。 後方互換のないドラスティックな変更 (強制バージョンアップが必要な更新) はよく行われますし、 拡張パッケージ発売とかマーケティング的にも盛り上がり所だったりしますしね。

というわけでご唱和ください

＿人人人人人人人人人人人人人人人人＿
＞　セマンティックバージョニング　＜
￣^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣

— feb19 (@feb19) December 16, 2015

次回、悪の必殺技「SQL インジェクション」（やらない）