構成管理¶
ソフトウェアのバージョニング¶
ソフトウェアのバージョニングは、開発者観点での構成管理ではなく、開発者と利用者との間で共有される構成管理の情報です。
バージョン１、２、３、‥‥という番号付け、2015、2017といった年に基づく番号付け、などいろいろあります。
近年、「セマンティック バージョニング」というバージョン付与の考え方が広まっています。
セマンティックバージョニング¶
3つの数値の組み合わせでバージョンを表現します。
<メジャーバージョン>.<マイナーバージョン>.<パッチバージョン>
パブリックAPIの変更と互換性を番号から読み取れるよう番号付けのルールを決めたもので、主にライブラリ・ソフトウェアのバージョニングに使われます。
また、アプリケーションのバージョニングにも有効と考えます。
- パブリックAPIの互換性のない変更をしたときはメジャーバージョンを更新
- パブリックAPIの互換性のある変更をしたときはマイナーバージョンを更新
- パブリックAPIの変更はなくバグ修正などを入れたときはパッチバージョンを更新
- 補足
- パブリックAPIの追加、非推奨宣言（動作はする）をしたときは、マイナーバージョンの更新
- メジャーバージョンを更新したときは、マイナーバージョンとパッチバージョンは0にリセットする
- マイナーバージョンを更新したときは、パッチバージョンは0にリセットする
- 開発初期はメジャーバージョンを0として（リリース前を意味する）、互換性のない変更もマイナーバージョンの更新としてもよい
- プレリリースを示す識別子を、パッチバージョンの後にハイフン記号を用いて付与してもよい（例、1.0.0-alpha2、3.1.0-1.2）
- ビルドを識別する識別子を、パッチバージョンの後あるいはプレリリース識別子があればその後にプラス記号を用いて付与してもよい（例、1.2.1+319、2.0.0-β+20190401.3）
アプリケーションのバージョニング¶
完成したアプリケーションを利用する場合、ユーザーとしては、バージョンアップに伴い利用の仕方が変わるかどうか、過去のバージョンで作ったデータファイル等が新しいバージョンで使えるか、などのアプリケーション内外のインタフェースがどのように変わったのかが気になるところです。
そこで、ユーザーが意識するアプリケーション内外のインタフェース、例えば、データファイル、設定ファイル等アプリケーションが外部に出力したデータ、アプリケーションが外部から入力するデータの互換性、画面操作の使い方の互換性をバージョン番号から読み取れるようにします。
- メジャーバージョンの増加は、入力データ、出力データに互換性のない変更があった場合、および画面操作に互換性のない（操作方法を学習し直す必要のある）変更があった場合を示します。
- マイナーバージョンの増加は、これまでの入出力データ、画面操作の互換性は保ちつつ、新しい入出力データの追加、画面操作の追加を示します。
- パッチバージョンの増加は、使い方に変化はないが、バグ修正を入れた場合を示します。
使い方は変わらないがバグ修正ではない実装の修正を入れた場合は、マイナーバージョンかパッチバージョンかどちらを更新するかはその都度判断事項になります。
セマンティックバージョニングを採用するとメジャーバージョンが頻繁に更新されますが、それはバージョニングとしては歓迎される事態です。
ソースコード管理¶
リポジトリの設定¶
ソースコードバージョン管理には、Gitあるいは他のバージョン管理ツールを使用して共有リポジトリを設け、開発関係者が共有して開発をします。