序

本記事では「私の」ソフトウェアバージョンの付け方を説明する。

このやり方は経験に基づく私独自のものだが、基本的にセマンティックバージョニングと似ており、バージョンに対する互換性の解釈はセマンティックバージョニング2.0と互換性がある。

別にこれに従うことが「良い」というわけではないが、セマンティックバージョニングとて結局のところ「誰かが言っているだけ」のものに変わりはない¹ので、参考になれば幸い。

ほとんどの場合

バージョンなどつけない。

発展していく予定がない、第三者に利用されることを積極的に想定していない、動作保証がないなど様々な理由である。

私が公開しているもののほとんどは、私が必要だから書いたものに過ぎず、他の人の環境を考慮してはいない。 一応、値をハードコーディングするのを回避したりといった配慮はして「使いうる」ようにはしているが、「使える」ようにはしていないのだ。

区別が必要な場合は、20240525のような日付で呼ぶか、GitやMercurialといったリポジトリのリビジョンで呼ぶ。

バージョンをつけている場合の基本

x.y.z方式をとっている。

この定義は

• x 双方非互換の変更
• y 前方非互換の変更
• z 互換性のある変更

である。

双方非互換の変更 (メジャーバージョン)

メジャーバージョンを上げるのは、そのバージョンの前後でどちらも動作しなくなる場合だ。

つまり、新しいもので動くものが古いもので動くことは保証されず、古いもので動くものが新しいもので動くことも保証されない。

これは内部ロジックに大きな変更を加えた場合も同じで、「動かないことを保証している」のではなく「動くことを保証できない」であることに注意してほしい。

前方非互換の変更 (マイナーバージョン)

新しいものではできるが古いものではできない、ということが発生する場合はマイナーバージョンを上げる。

これはほとんどは新機能の追加である。

互換性のある変更 (パッチバージョン)

理屈上の互換性はたもたれている変更をパッチバージョンとして上げる。

これは、バグ修正やロジックの改善、コードの修正、ドキュメントの修正などを含む。

これによってバグが修正されて正しく動くようになったり、あるいはバグが追加されて正しく動かなくなったりしたとしてもマイナーバージョンは変更しない。

後方非互換の変更の場合

機能を廃止するなどの後方非互換変更は、メジャーバージョンを上げる場合とマイナーバージョンを上げる場合がある。

前のメジャーバージョンで既にdeprecatedであったものを廃止するときはマイナーバージョンに留める。

deprecatedの予告もなく廃止したものはメジャーバージョンを上げる。

同一メジャーバージョンで長くdeprecatedであったものを廃止するときも、メジャーバージョンを上げる。

内部的な変更

変更の「互換性に影響がない」の判断は、「ドキュメントになっている機能に対して」である。

例えばclassのpublicなメソッドであったとしても、ドキュメントに書いていないものは保証しない。

バージョン0の場合

セマンティックバージョニングと似たような感じで、マイナーバージョンが上がったものは互換性が保証されていない。

パッチバージョンでも保証はしていない。

セマンティックバージョニングとの主な違い

API以外

セマンティックバージョニングではAPIしか書いていないけれど、私は設定ファイルの変更や、アプリ内で使える機能の変更も対象としている。

セマンティックバージョニングがライブラリを念頭においている感じがあるのに対して、私のバージョニングは私のリリースするもののためだからだ。

明示

API以外も含めるので、「public APIを全部書け」という部分に関しては根本的な解釈の違いがある。

私のバージョンの場合、「ドキュメントに書いてあるもの」が対象だ。

開発バージョン

開発バージョンはセマンティックバージョニングに書いてあるalphaのような識別子は用いず、あくまで日付、もしくはリビジョンで呼ぶ。

というよりほとんどの場合、開発バージョンはdev HEADとしか呼ばない。 HEAD以外を話題にする必要があるのは、そのソフトウェアを作っている人だけ(つまり私だけ)だからだ。

ちゃんとしたバージョンがついているのは、すべてリリース版である。

後方非互換

セマンティックバージョニングではdeprecatedな機能を削除するときはメジャーバージョンを上げるように書いてあるが、私はマイナーバージョンの途中で上げることがある。

これは、セマンティックバージョニングよりも「早く」なくすことはない。

例えばセマンティックバージョニングでは2.5で非推奨としたら、2.6をリリースして3.0で消せということになっている。

が、私の場合は2.5で非推奨としたあと、別の理由で3.0がリリースになって、その後の3.2で削除といったことがある。

つまり、お互いに2.xでは削除されないが、セマンティックバージョニングが削除する機会が3.0なのに対して、私の場合は3.xになるということだ。

ちなみにこのようにしているのは、非推奨機能の削除が簡単ではないことがあり、メジャーバージョンを上げるとなるとそのせいでメジャーバージョンのリリースができないということが生じるからだ。

バージョン形式

x.y.z方式しかつけず、1.1.0-alpha+001みたいなバージョンはつけない。

保証しない

セマンティックバージョニングは「互換性があるかどうかわからない場合」について言及がない。

私のバージョンをつける基準は「保証しない」である。 これは、動作しないことを確信していることもあれば、確認していないこともある。

バージョンのつけはじめ

基本的にはソフトウェアに互換性のない変更を加え、継続的にメンテナンスしていきそうな予感がした場合につけるようにしている。

他の人が使うことを最初から想定しているものは、最初からつけていたりする。