はじめに

バージョン 、という言葉があります。
バージョン管理システムとかに使われるあのバージョンですね。

しかし、あのバージョン、色々な形式があると思いませんか？
身近なところでいっても、

Windows
- Windows 10 バージョン 1607 (OS ビルド 14393.693)
Google Chrome
- バージョン 55.0.2883.87 m
Slack
- 2.4.1

など、よくよく考えてみるとそれぞれの数字が表しているものがなんなのかよくわからないことに気が付きます。
なので バージョン というものについて調べてみました。

なお、本来的にバージョンの付け方は 開発者の自由 ですので、こちらにまとめた内容でこの世の全てのバージョンが説明できる保証はありません。
ただ、一言に言ってしまいがちなバージョンについて、こちらにまとめたアイデアで少しでも コミュニケーションが円滑に なればと思っています。

ではバージョンに類する言葉や、バージョンと一緒に使われたりする言葉をそれぞれみていきたいと思います。

数字によるバージョン

最初は数字を使ったバージョンです。

メジャーとマイナー

メジャーバージョン や マイナーバージョン という言葉を聞くことは多いと思います。
例えば2桁で バージョン2.1 と書いたとき、

メジャー		マイナー
2	.	1

のように、数字の先頭にくるものをメジャーバージョンと呼ぶことが多いです。
また、メジャーバージョンに続く2桁目の数字がマイナーバージョンと呼ばれます。

ではどういう基準でメジャーとマイナーのバージョンアップを使い分けるかですが、個人的にメジャーのほうでは仕様や動作要件の変更が発生する場合に選択されている気がします。
UI的なものであったり、スペック的なものであったりと変更の形は様々ですが「ユーザ体験を大きく変えるもの」というイメージがあります。
一方で、マイナーのほうでは仕様や動作要件を維持したまま機能追加やバグフィックスが行われる印象です。

ビルドとリビジョン

メジャーとマイナーほど メジャーではない ...失礼しました。
メジャーとマイナーほど一般的ではないのですが、これらに続くものとして ビルド と リビジョン などが存在します。
こちらはさらに2桁加えて、4桁で バージョン2.1.4.3 と書いたとき、

メジャー		マイナー		ビルド		リビジョン
2	.	1	.	4	.	3

のように呼ばれることがあります。
ビルド番号などはまさにパッケージをビルドするときの番号として、人間ではなくCIシステムなどが機械的に与えている場合があります。
そうした場合、メジャーやマイナーと違い、全てのビルド番号のソフトウェアが日の目を見るわけではなく、飛び飛びの番号でユーザにリリースされることも多くみられます。

また、これらに類するものとして パッチバージョン や メンテナンスバージョン なんてのを耳にすることがあります。
いずれにせよ、メジャーとマイナーほど一般的ではないので、バージョン数字の3桁目や4桁目に共通的な意味づけをすることは難しいと考えられます。
とはいえ、それらが存在するソフトウェアでは3桁目や4桁目を与えるタイミングがしっかり決まっていたりするため、それらを明確に知ることで、ソフトウェアの状態がよりよく分かるようになると思います。

版と刷

数字とバージョンというところで少しソフトウェアから離れてみます。
お手元に何か本はあるでしょうか。
後ろから数ページめくったところに、発行日や発行所の情報を書いたページがあるかと思います。

敗者のゲーム ( 原著第 6版 )
2015年1月23日 1版1刷
2016年3月29日 4刷

このように、本で言うところのバージョンが版と刷になります。
一般的に、版が変わると本の内容も変わります。
この本の場合、少しややこしいのですがタイトルの部分に「原著第 6版」というものが入っています。元々は英語の本で、原著のほうに5回の内容更新があり第6版まで到達しているのですが、それ毎に翻訳されているため和書としては別の本扱いになっています。
その上で改めて理解していくと、まずこの本は「敗者のゲーム (原著第6版)」という本の和訳であるというのが第一歩になります。
そして、その和訳された本の中で第1版のものがこの本です。
何のこっちゃという話ですが、大筋の内容が変わらない場合でも訳文修正などの都合で版が上がったりする場合があります。
一方で、刷のほうは単純によく売れたので追加で刷っただけということになります。増刷ってやつですね。

先ほどのメジャーとマイナーあたりの言い方をイメージすると、「敗者のゲーム 6.1.4」というところでしょうか。

重版、再版

先ほど、「版が変わると内容が変わる」と書きましたが、これが全く正しいかというとそうでないイメージの言葉も使われています。
それが重版や再版です。

これらの場合、意味合い的には増刷と同じなのですが、言葉的なインパクトからなのか版という言葉が使われます。
( 重版出来という漫画やドラマがありましたね )

記号によるバージョン

次に記号や言葉を使ったバージョンを考えてみましょう。

α, β

α版とか β版も意外とよく聞く言葉なのではないかなと思います。
おそらく普通に会話を聞く分には「 未完成のバージョン 」というくらいの理解かなと思いますが、ソフトウェア開発の状況を反映して、下記のような意味で使われます。
公開対象について書いていますが、開発が進むに連れて触る人が増えていくというイメージを持っていただければと思います。

バージョン	意味	公開対象
α	実装予定の機能について、未実装が存在する状態。大まかな使い勝手や性能をチェックする段階。	チーム
β	実装予定の機能について、実装が完了した状態。ただしデバッグが不十分で、製品としての安定性に不安がある状態。	チーム
γ	製品出荷前のほぼ最終バージョン。α, βに比べると知名度が圧倒的に低く、意味的には後述のRC版がよく使われる。	一部のユーザ
pre-α	α版よりもっと荒削りな状態。	一部の開発者
public-β	デバッグを経てβ版より安定性や安全性が担保され、さらなるデバッグのためテスターを一部ユーザに拡げた状態。オンラインゲームやクラウドサービスなどに見られる。	一部のユーザ

いろいろ

バージョンには接頭字を使った略語が使われることも多くあります。
順にみていきましょう。

Nightly build

「昨晩の(Nightly)」というところからくる、 最新ビルド という意味です。
開発者が日夜開発している最新コードから生成されたパッケージがNightly buildです。
もちろん正式リリースではないものですので、リスク承知で最新機能をいち早く使いたいユーザ以外にはオススメされないものです。
有名なものとしては Firefox がNightly buildを提供していたりします。

RC(Release Candidate)

Candidateは候補者という意味です。Presidential candidateで大統領候補者ですね。
そのため、 RC版 というのは　リリース候補版 という意味になります。

α→β→public-βなどと順調に機能開発とデバッグを進めてきたとき、「もう(ほとんど)これだな！」という状態がRC版です。
RC版でもRC1からRC4までとか番号付きでいくつか重なったりはしますが、一般的にRC版に到達した場合は仕様の変更はもちろん、挙動の変更も一般的には起こらないことが望まれます。
RC版で修正されるのは主にtypoとか、分かりづらいメッセージの修正など軽微なものですね。

Ansible なんかもマイナー毎にRC版を出してくれるリリースサイクルを取っているので、RC版が出てきたら新機能や使い勝手なんかを試し始めることが多いです。

GA(General Availability)

ソフトウェア開発において GA版 が出るということが一旦のゴールになります。
当初想定していた機能の開発、デバッグが完了し、 一般的に利用可能な状態 となった状態です。
ゼロから始めた開発が初めてGAになったタイミングで バージョン1.0 を置くところも多いかと思います。

とあるソフトウェアの新バージョンを待っている人がいたとして、「正式版はいつ出ますか？」と聞かれたらGAされるタイミングを教えてあげましょう。

Stable, Develop

Stableはいわゆる 安定版 と呼ばれるものです。
Stableを特徴的に述べる文脈であれば、対になる存在はおそらく Develop(開発版) です。

これは主に開発ラインをどう持っているかどうか、 git-flow　に出てくる各ブランチがどういう用途かどうか、そのブランチ上に存在するコードがどういう品質のものかという話にも近いです。

バージョンの仲間

多分バージョンとひとくくりにすると怒られると思うのですが、何かを区別するための仲間としていくつか考えてみたいと思います。

エディション

同名のソフトウェアでも、

エンタープライズ版
コミュニティ版
無償版

のような エディション の違いを見たことはないでしょうか。
バージョンの概念とはまた異なりますが、一般的にエディションの違いは有効機能の違いとして現れます。

例えば、こちらを見てみて下さい。

vSphere 6.x の各エディションにおける機能一覧

この中ではHypervisor(Free)版からEnterprise Plusまでいくつかのエディションがラインナップされており、表のように各エディションごとに 利用できる機能に差がある ことがわかります。
エディションによる差別化はベンダー製品において顕著でしたが、時間課金モデルのクラウドサービスや、自由な開発と利用を旨とするOSS利用が広がるとともに、エディションによる機能制約を意識する局面が減ってきているかもしれません。

一方で、OSS版をベースとしながら差別化機能だけを独自実装することで価値を出そうとしている製品も見られるようになってきました。

Gitlab
- OSSのGitホスティングソフトウェア
- 無償のコミュニティ版と大人数利用を想定したエンタープライズ版などが提供されている
EnterpriseDB
- OSS DBである PostgreSQL の有償拡張版
- Oracleとの互換性やミッションクリティカルレベルの安定性などで差別化

ディストリビューション

ディストリビューションについても意外とピンとこない方も多いのではないでしょうか。
おそらく最もディストリビューションが語られやすいのは Linuxディストリビューション かと思われますが、

RedHat系
- Red Hat Enterprise Linux
- CentOS
Debian系
- Debian
- Ubuntu

あたりを聞いたことがある方は多いと思います。
これらは全てLinuxと総称され、同様のLinuxカーネルを用いています。
しかし、OS全体の使い勝手を パッケージ管理システム や デスクトップ環境 などで差別化を図っており、それらが独立したディストリビューションを名乗っているというわけです。

ちなみに、ちゃんと調べたことがない人にとっては本当に 驚くほどたくさんの Linuxディストリビューションが存在します。
その多さを GNU/Linux Distribution Timeline で見ることができるのでぜひ一度みてみてください。

コードネーム

製品の新バージョンを開発していく際に、親しみ(と分かりやすさ)を込めて コードネーム で呼ぶことがあります。
昔は開発チーム内でしか登場していなかったコードネームですが、最近ではAndroidを代表として、コードネームがそのまま製品名として知られるなど、メディア戦略としてそのまま利用されることが増えたように思います。

古くは開発者で面白おかしく決めるだけのものでしたが、最近では一定のルールやモチーフを使ってコードネームを与えることも多くなってきました。
以下に例を挙げてみます。

タイプ	製品	コードネーム例	説明
アルファベット&お菓子	Android	Apple Pie, Banana Bread, Cupcake, ...	お菓子の名前を用いつつ、名前の頭をアルファベット順に。現行のAndroid 7.0がNougat。
アルファベット&地名	OpenStack	Austin, Bexer, Cactus, ...	OpenStack Summit開催地に関連のある地名を使いつつ、名前の頭をアルファベット順に。日本からはMitaka(三鷹)が選ばれています。現行がNewton。
アルファベット&動物	Ubuntu	Trusty Tahr, Utopic Unicorn, Vivid Vervet, ...	Ubuntuはリリースごとに開発コードネームを設定していますが、アルファベット順かつ [形容詞]+[動物名詞] の形式をとっています。6.06 LTS Dapper Drakeから始まったこのルールですが、最新のUbuntu 17.04ではZesty Zapusというように、ついにZに到達しました。以降のバージョニングが気になります。
ネコ科	Mac OS X	Cheetah, Puma, Jaguar, ..., Mountain Lion	最近はYosemite(ヨセミテ国立公園)など自然シリーズになったようです。
物理学者	NVIDIA GPU	Tesla, Fermi, Kepler, ...	アーキテクチャのコードネーム。現行がMaxwell世代。
語尾合わせ	Intel CPU	Sandy Bridge, Ivy Bridge, Haswell, Broadwell, ...	アーキテクチャのコードネーム。現行がKaby Lake世代。
特定アーティストの曲名	Ansible	Dancing In the Street, Over the Hills and Far Away	マイナーバージョンごとのコードネームとして特定アーティストの曲名がつきます。バージョン1系はVan Halen、バージョン2系はLed Zeppelinです。

バージョンいろいろ

あとは見ていてユニークだなーと思った製品のバージョンやらコードネームやらを紹介します。

Zabbix, Ubuntu

Zabbix や Ubuntu はLTS(Long Term Support)の考え方を導入し、特定のバージョンにおいてサポート期間を長く持っています。

そのため、ZabbixやUbuntuをサポートありきで導入検討する場合は、

Zabbix
- 2.0, 2.2, 2.4, ...
Ubuntu
- 12.04, 14.04, 16.04, ...

という飛び飛びのバージョンで利用検討することになるでしょう。
ちなみに後述するOpenSSLもLTSを採用しています。

Ubuntu

コードネーム、LTSに続き3度目のUbuntuですが、バージョニング自体もちょっと面白いものになっています。
Ubuntuの バージョン は「Ubuntu 16.04 LTS Xenial Xerus」のように表されますが、数字の部分に着目してみると

14
- 14.04
- 14.10
15
- 15.04
- 15.10
16
- 16.04
- 16.10

というように、マイナーの部分には「04」と「10」しか出てきません。
リリース一覧のページをスクロールしていくと、

Release cadence
- Releases are published in a time based fashion, every 6 months, following a planned schedule.

というのが出てきます。聞き慣れませんが、cadenceは芸術的な意味での リズム を意味します。
これを読んでも分かる通り、Ubuntuでは時間ベースのリリース戦略を採用しており、6ヶ月間隔でのリリースがなされるようです。
そのため、「04」は4月、「10」は10月を表しているということになります。

ちょっと長いですが TimeBasedReleases を読んでみるとUbuntuとしての考え方がわかります。

ちなみに 16.04.1 のような3桁目の番号は バグフィックス のリリースを表します。
この場合、機能的には 16.04 と同等ですが、それまでに出たバグフィックスを取り込んだということになります。
LTSはサポート期間が長い分、そうでないものに比べてバグフィックスのバージョンも多く出ていることがわかります。

Ubuntuの他に時間ベースのリリースをしている製品で言えば、 GitLab が 毎月リリース をしていることで有名です。

Oracle Database

データベース製品として有名なOracle Databaseですが、よく見ると製品バージョンに小さなアルファベットがついています。
実はこれらはそのバージョンにおいて目玉とされる機能や技術を象徴したものとなっています。

Oracle Database 8i
Oracle Database 9i
- internetからとっている。インターネット時代に対応するデータベースを象徴。
Oracle Database 10g
Oracle Database 11g
- gridからとっている。Oracle RACに代表されるデータベースグリッド技術を象徴。
Oracle Database 12c
- cloudからとっている。Pluggableアーキテクチャによるマルチテナント技術でクラウド対応を象徴。

nginx

nginxはダウンロードパッケージのページを見てみると、

Mainline
Stable
Legacy

という3つのラインが見えます。
Legacyはまぁ古いんだろうな、というところですが、MainlineとStableはどちらも良さそうな雰囲気が漂います。
この点は皆さん思われているようで、要約すると

どのバージョンのnginxを使うべきか？

nginxのバグ修正はまずmainline版に取り込まれる。しかし、stable版には緊急度の高いバグ修正しか取り込まれない。だから mainline版の方がバグはよく取れてるし、安定してるよ 、ということらしい。

ということのようです。
nginxのMainlineはStableより安定している。 これ大事。

OpenSSL

人がソフトウェアのバージョンを気にする時が一体どういうときか。
そういう問いかけをした時に挙がるシチュエーションの1つに「 脆弱性が発覚したとき 」があると思います。

OpenSSL はセキュア通信において非常に重要かつ広範に活躍するため、その分脆弱性が発覚しやすく、かつ対応判断を迅速に行わなければならなかったりします。
しかし困ったことに、こいつのバージョンは わかりにくいのです。
試しに、以前巷を賑わした Heartbleed の影響範囲を確認してみましょう。

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable

はて...？
vulnerable(脆弱性あり)とかNOT vulnerable(脆弱性なし)とか言っていますが、結局どうなんでしょう。
0.9.9 がどこにいったかも気になります。
1行目を素直に読むと、「 1.0.1から1.0.1fまで 」とか言っているような気がしますが、この 数字 + アルファベット のパターンは初めてです。

OpenSSLの バージョン感 (?)を掴むには、

メジャーリリースサイクル
バージョニングルール

を把握する必要があります。

メジャーリリースサイクル

Wikipediaの メジャーバージョンアップ履歴 を見てもらうといいのですが、3桁を刻んでいる割には、メジャーの位置がなんと3桁目にあることもあります。

OpenSSL 0.9.3 : 1999年3月25日
OpenSSL 0.9.4 : 1999年8月9日
...
OpenSSL 0.9.8 : 2005年7月5日
OpenSSL 1.0.0 : 2010年3月29日
OpenSSL 1.0.1 : 2012年3月14日
OpenSSL 1.0.2 : 2015年1月22日
OpenSSL 1.1.0 : 2016年8月25日

0.9.3から順に刻んでいると思いきや、0.9.8から1.0.0にジャンプしていきました。
同様に、1.0.2から1.1.0に飛んでいます。
このあたりは冒頭に前置きしたように開発者の自由というのがある意味よく現れているところかなと思いますので、最初に感じたような「 0.9.9 is どこ？ 」みたいなことは考えたら負けということですね。

まず、これによって3桁の番号を使ってメジャーを特定していることがわかります。
より正確に言えば、 Github 上で開発ブランチの用意されているものがそれぞれの開発ラインとリリースを持っています。

バージョニングルール

Release Strategy

こちらに細かいバージョニングルールが書かれています。大事な部分を抜き出すと、

Letter releases, such as 1.0.1a, exclusively contain bug and security fixes and no new features.
(1.0.1aのような文字リリースでは、バグとセキュリティ修正のみで、機能追加は行いません。)

というところと、

Minor releases that change the last digit, e.g. 1.0.1 vs. 1.0.2, can and are likely to contain new features, but in a way that does not break binary compatibility.
(1.0.1から1.0.2のような末尾の数字を変えるリリースでは、機能追加を含みますが、バイナリレベルの互換を崩すようなものではありません。)

というところかと思います。
このルールを考慮すると、Heartbleed脆弱性に関しては

(脆弱性なし) 1.0.0 branch
(脆弱性あり) 1.0.1 branch
- (脆弱性あり) 1.0.1a
- ...
- (脆弱性あり) 1.0.1f
- (脆弱性なし) 1.0.1g
- ...

のような状況であると読み取ることができます。
ちなみにリリース履歴を見ると、1.0.1系に関しては 1.0.1u まで進んだようですね。

Chrome

冒頭にも例で出しましたが、やたら長いのがChromeです。

バージョン 55.0.2883.87 m

この場合、Chromeの元となっているChromiumの Version Numbers を参照すると、

メジャー		マイナー		ビルド		パッチ	？？
55	.	0	.	2883	.	87	m

にあたるようです。最後の m が何にあたるのかはよくわかりませんでした。。。
メジャーの使い方が開発者次第とはいえ、Chromeの上がり方は他の追随を許さないレベルですね。
OmahaProxy CSV Viewer を見ると、バージョンがぐいいと上がっていく様を見ることができます。

OpenSSH

こちらは @sakuro さんからコメントにて情報提供頂きました。

OpenSSHのバージョン(7.4p1など)の p の意味もあまり知られていない気がします。
Patchのpじゃなくて、portableのpなんですよね。 OpenBSD用に 7.4 が作られて、他のプラットフォームへの移植バージョンがp付きになる。

調べてみると、 ダウンロードページ のところにこっそりとこのような記述があります。

The portable OpenSSH follows development of the official version, but releases are not synchronized. Portable releases are marked with a 'p' (e.g. 4.0p1). The official OpenBSD source will never use the 'p' suffix, but will instead increment the version number when they hit 'stable spots' in their development.
(ポータブル版のOpenSSHは公式バージョンに追従しますが、同期されているわけではありません。 ポータブル版は "4.0.p1" のようにp付きのリリースとなります。 公式のOpenDSD版がバージョン末尾にpを使うことはなく、開発が '安定点' に達した場合に数字を上げることになっています。)

あまりにOpenSSHがスタンダードすぎて意識したことはなかったのですが、OpenSSHは元々 OpenBSD 向けに開発されました。
しかし、OpenSSHの便利さはOpenBSDに閉じるものではないですから、Linuxをはじめ多くのプラットフォームに移植(Porting)されています。
そのとき、SSHの仕様に準拠したコアな処理部分をまずOpenBSD版へ公式版として実装し、その後公式版のうちOpenBSD固有の部分を各プラットフォームに沿った形で書き換えるスタイルをとったようで、移植版がどの時点のコア機能を持っているのか明示できるようにベースとなったOpenBSD版のバージョン末尾にpをつけるようになったとのことです。

確かにバージョン末尾にpがついていると、ついパッチバージョンと思ってしまいがちですが、これはポータブルのpなんですね。
これまたユニークなバージョニングでした。

ニコニコ動画

全然関係ないですが、実はニコニコ動画もサービスの立ち上げから現在に至るまでバージョンを表す表記が用いられています。

ニコニコ動画(仮)

こちらは公式のニコニコ大百科ページですが、「ニコニコ動画の変貌」という項目で、

(仮) → (β) → (γ) → (RC) → (RC2) → (SP1) → ... → (GINZA)

というようにサービス名称(?)がこっそりと変わっていっていたことがわかります。
ニコニコ動画を初めて使ったのは、IT業界に入るイメージすら持っていなかった頃ですが、サービス名称がちまちま変わっていくのが気になって初めて RC の意味を調べたような気がします。
おそらくそういう意味では、 非IT業界人の目にも入りうる唯一のRC版 だったのではないかなとこれを書いていて思いました。

さいごに

世の中には本当に色々なバージョンがあるとわかりました。
宣伝目的でうまいことバージョンの文化を利用しているフシも最近はありますが、本質的には コミュニケーションを助ける ためのアイデアだと思っています。

「開発 どのへんまで 進んだ？」
「今 α版くらい。とりあえず触る？」
「あとで触ろうかな。 β版までだとどれくらいかかりそう？」
「β版ってことであれば あと2週間 くらいかなー。」

というような会話も、バージョンに関する認識が揃っていればスムーズにできるようになるのではないでしょうか。
この記事が話のタネになることを含め、コミュニケーションの一助になれば幸いです。