日付を元にバージョンを定める「カレンダー・バージョニング」という考え方

現在までにさまざまなソフトウェアが開発されてきましたが、その開発において、プロジェクトの大小を問わず問題になってくるのがソフトウェア同士の依存関係です。バージョン管理はその正確な依存関係を指定するのに役立ってきました。現在、バージョンの管理方法は2つあり、一つは例えば「3.1.4」というような点で区切られた数字で、もうひとつはリリース日の日付や時間を組み込んだ「CalVer」と呼ばれるものです。CalVerがどのようなバージョン管理を行うのかを見ていきます。

Calendar Versioning - CalVer
https://calver.org/

プロジェクトはそれぞれの規模や開発期間に合ったバージョン管理スキームがあります。重要なのはCalVerを単一のスキームで運用することではなく、CalVerとインクリメンタルな数字のそれぞれの実用性を認識してプロジェクトに合ったスキームを設計することです。一般的に使用されているスキームは以下のようなものです。

・メジャーバージョン
バージョンの最初の数字で、例えばPythonであれば2や3が有名なメジャーバージョンです。CalVerはこのメジャーバージョン部分でよく使用されます。

・マイナーバージョン
バージョンの2番目の数字です。例えば2.x系のPythonで最も有名なマイナーバージョンは7です。

・マイクロバージョン
バージョンの3番目の数字です。「パッチ」セグメントと呼ばれることもあります。

・修飾子
「dev」「alpha」「beta」「rc1」などのオプションテキストです。

例えばメジャーバージョンが2、マイナーバージョンが7、マイクロバージョンが15でリリース候補(Release Candidate)のバージョンは「2.7.15rc1」のように表記されます。

CalVerでない場合はバージョンアップごとに番号は1ずつ進んでいきますが、CalVerを採用した場合バージョン番号にはリリース日に基づいた数字が入ります。通常はUTCが使用されます。例えばMicrosoft製OSのウィンドウズでは95や98、2000といったバージョン番号がCalVerを使用したものです。よく使用されるCalVerの例は以下のとおり。

・YYYY
2006、2016、2106などの西暦がそのまま入ります。JavaScriptのバージョンであるECMAScript2015など多数の例があげられます。

・YY
6、16、106など西暦のショートバージョンです。Windows 95やWindows 98などはこのパターン。

・0Y
06、16、106など西暦の頭をゼロ埋めしたものです。

・MM
1、2、……、11、12などの月が入ります。

・0M
01、02、……、11、12など、月の頭をゼロ埋めして桁を合わせたものです。

・DD
1、2、……、30、31などの日付。

・0D
01、02、……、30、31など、日付の頭をゼロ埋めしたもの。

ウィンドウズ以外の例では、Linuxディストリビューションの一つである「Ubuntu」や「ArchLinux」があげられます。UbuntuのバージョンはCalVerの「YY.0M」形式となっており、例えば2004年10月にリリースされたバージョンは4.10であり、2017年4月にリリースされたバージョンは17.04となっています。ArchLinuxのバージョンは2018.06.01のような「YYYY.0M.0D」形式で、いつリリースされたのかが一目瞭然です。

このようなCalVer形式を使用することで、サポートの期限を明確にできたり、巨大なシステムを運用するプロジェクトにおいてバージョン番号が追加の情報を伝達してくれるというメリットを享受することができます。