セマンティックバージョニング(SemVer)について、公式のページを見て簡単にまとめてみました。
Semantic Versioningについて
Laravelはバージョン6からセマンティックバージョニングが採用されています。
公式のこの辺りに書いています。
セマンティックバージョンニングについては、こちらに書いています(公式)が、ちょっと読みづらいです…
公式のgithubはこちらです。
ソフトウェアのバージョンの付け方に意味を持たせることらしいです。
X.Y.Z でバージョンを管理します。
・Xはメジャーバージョン
・Yはマイナーバージョン
・Zはパッチバージョン
Laravelの例で言うと、下記のようにコマンドでプロジェクトのバージョンを調べると、6.18.15でした。
$ php artisan --version
Laravel Framework 6.18.15
6.18.15なので、6はメジャー、18がマイナー、15がパッチです。
それぞれの意味合いは、公式の最初には、このように書いています。
APIの変更に互換性のない場合はメジャーバージョンを、
後方互換性があり機能性を追加した場合はマイナーバージョンを、
後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。
引用:https://semver.org/lang/ja/
筆者が見た感じで、まとめてみると、下記のようなルールのようです。
全体的な決まり
・バージョンはX.Y.Zの形式にする必要がある。X.Y.Zは正の整数で定義する。各数値の先頭に0をつけてはいけない。
・一度リリースしたら、そのバージョンは触らない。修正がある場合は新しいバージョンでリリースする。
・開発バージョンは0.y.zで開発して、マイナーバージョン以降を上げていく。
・開発バージョンは修正を頻繁にしても良い。安定したバージョンではないと考える。
・最初のリリース時に1.0.0のバージョンにする。
メジャーバージョン(X)
メジャーバージョンは、後方互換性を持たない変更があった場合に上げる。その際にはマイナーおよびパッチレベルの変更も含めてもいい。
メジャーバージョンを上げた際には、パッチおよびマイナーバージョンを0にリセットする必要がある。
マイナーバージョン(Y)
マイナーバージョンは、後方互換性を保ちつつ機能性を追加した場合に上げる。
一部の機能を廃止した場合も上げる必要がある。
新しい機能の追加や改善を取り込んだ場合は上げてもいい。その際にはパッチレベルの変更も含めることが可能。
マイナーバージョンを上げた際にはパッチバージョンを0にリセットする必要がある。
バッチバージョン(Z)
後方互換性を保った、バグ修正を取り込んだ場合のみ、パッチバージョンを上げる。
なぜセマンティックバージョンを使うのか
公式には、なぜセマンティックバージョンを使用するのかで、下記のように書いていますね。
正式な仕様書による取り決めがなければ、バージョンナンバーは依存性の管理において基本的には無意味です。
上記のアイデアに対して名前と正確な定義を与えることよって、あなたの開発するソフトウェアにおいて、あなたの意図がユーザーに対して伝わりやすくなることでしょう。
引用:https://semver.org/lang/ja/
なるほど…
SemVerを採用してバージョン管理すると、チームのメンバーもちゃんと理解しておく必要はあると思いますが、バージョンに対する考え方が整理されて良さそうですね。
さらに、ユーザーも理解していれば「Zが上がっているからパッチ。Yが上がっているから機能修正があったのか..」という感じで理解できるということですね。
公式の仕様書には、さらに詳しく書いてあるので読んでみてください。
おわりに
今回はSemantic Versioning(SemVer)を見ていきました。
ソフトウェアのバージョン管理の記載方法って、他にもないのかな…？と思い調べましたが、SemVerがよく使われているようです。
今後は自分で何か作る場合にも、使っていきたいと思いました😌
コメント