一度確認しておきたいSemantic Versioning
Version Semantics
体系的に、Version Semanticsを学んで行こうと思います。
動機としては、今年から新卒としてエンジニア職につくので、チームで齟齬が生じないように事前に知識をつけるのが目的です。
セマンティックバージョニングは公式ドキュメントだと、それ自体は2.0.0のバージョンみたいです。
モジュール
Semanticsバージョニングに使えるライブラリやモジュールはいくつもありますが、一つだけ紹介します。
Batchもあったり、ドキュメントが豊富です。
Version Semanticsとは
Version Semanticsとは、シンプルなルールセットとバージョン・ナンバーをどのように割り当て、バージョンを上げていくのかについての要件のことをいいます。
X.Y.Z（メジャー.マイナー.パッチ）のバージョン形式になっていて、非常にわかりやすく、このようにバージョンを管理することをセマンティック バージョニングと呼びます。
Major, Minor, Patchのバージョンの上げ方
バージョンは以下のルールで変更します。
- Major: APIの変更に互換性のない場合
- Minor: 後方互換性があり、機能性を追加した場合
- Patch: 後方互換性を伴うバグ修正などの軽微な変更
バージョン上げるがどのような変更であるかを考える必要があるというわけです。
重要なルール
1. セマンティック バージョニングを明示的に書く
バージョニングにセマンティック バージョニングを使用していることを明示する必要があります。
2. X.Y.Zの形式であるべき
X, Y, Zは非負の整数でなければならず、Major, Minor, Patchのバージョンの上げ方で定めるように各々の数値はメジャー、マイナー、パッチバージョンに値します。
3. パッケージはリリース後の変更は認めらない
いかなる修正も新しいバージョンとしてパッチを当てないといけません。
4. 5. メジャーバージョンが0は開発段階、1.0.0はパブリックAPIを定義
0.1.3のように0がメジャーバージョンになっているものは、開発段階であり、1にあがるとパブリックAPIを定義します。
6. パッチバージョンZは後方互換性を保持したバグ修正を取り込んだときのみ上げないといけない
バグを発見して、さっと直したときはパッチバージョンをアップデートします。
7. マイナーバージョンYは後方互換を保ちつつ、機能性をパブリックAPIに追加したとき、APIの廃止予定ならに上げないといけない
プライベートコード(=パブリックAPIではないコード)に機能を追加したり、改善を行ったときは上げてもよいです。
つまり、この場合はどっちでもよいということです。
8. メジャーバージョンXはパブリックAPIに対して後方互換性のを持たない変更が取り込まれた場合は上げないといけない
これは後方互換性がないことが重要です。
大体の場合は、ドキュメントを残すことが望ましいでしょう。
9. プレリリースバージョンは、パッチバージョンに続いてハイフンとドットで区切ってもよい
これは厳密なルールではないですが、2.0.0-betaや4.3.3-alphaなどのようにプレリリースバージョンを定義することができます。
もちろん3.0.0-alpha.2のように.2をつけることもできます。
まとめ
このページは随時、更新していこうと思っています。
開発者は、殆どの場合はセマンティック バージョニングを使用しているかと思いますが、何かしら知見が溜まったら、ここに追加で書き留めるようにします。
短いですが、これにて終わりにしようと思います。
参考文献
より詳しく知りたい方は、以下のリンクをご覧ください。
