.NETのライブラリのVersion番号（1.2.3.4）の管理方法のメモ
はじめに
自分はHigLaboというレポジトリでC#のライブラリを公開してます。
・HigLabo.Mapper（世界最速のオブジェクトマッパー）
・DbSharpApplication（ストアド実行のC#コードの生成ツール）
・HigLabo.Data.XXX（Dapper ORMのようなDatabaseアクセスのライブラリ）
・HigLabo.OpenAI（OpenAIのC#クライアントライブラリ）
・HigLabo.Net.Slack
・HigLabo.Net.Microsoft（GraphAPIのクライアントライブラリ）
などを公開しています。
今まで結構適当にバージョンを付けてたので改めて整理してみました。
一般的なバージョン管理方法
まず一般的なバージョン番号の管理方法としてセマンティック バージョニング 2.0.0があります。
Stackoverflowを覗くと
1: Major revision (new UI, lots of new features, conceptual change, etc.)
9: Minor revision (maybe a change to a search box, 1 feature added, collection of bug fixes)
0: Bug fix release
1: Build number (if used)—that's why you see the .NET framework using something like 2.0.4.2709
まあいろいろな方法がありそうです。基本的には開発者が自由につけて良いというのがこのバージョン番号です。
.NETでの自分がやっている方法
.NETのライブラリの場合、どの.NETのバージョンで動くかが大事です。なので自分の場合は
メジャー番号は.NETのバージョンに合わせています。
で残りをどうするかを今回整理してみたので自分用にメモしておきます。
メジャー: .NETのバージョンと同じにする
マイナー: 後方互換性がない変更（メソッド名をLoadRecords→LoadRecordListとか）
ビルド: publicな機能の追加（LoadDataメソッドを追加した、とか）
リビジョン: 内部実装の改善
という感じで管理することにしました。
public、protectedなプロパティ、イベント、プロパティの変更はマイナー番号を上げる。
→使ってる人は変更が必要になるかも。
新規にメソッド、イベント、プロパティを追加した場合はビルド番号を上げる。
→使ってる人は既存のコードの変更の必要なし。
という感じでいくことにしました。これであまり悩まなくなりそうです。
Discussion