たまにソフトウェアやアプリケーション（スマホアプリなど）でバージョン情報と思われる数字の羅列を目にしますが、実際のところバージョン情報の意味を知識として持っている人は少ないと思います。
例えば、Webブラウザの Google Chrome だと以下のようなバージョン表記がされていますね。画像は少し古いバージョンのものです。
開発が盛んな Google Chromeは、上の画像のようにかなり細かいバージョン管理がなされていることが察せられます。
-
PC版 Google Chromeのバージョン情報を確認する方法
続きを見る
もちろん、利用中のバージョンに問題がない限り、基本的にはユーザーが細かい数値のバージョンを気にする必要はありません。小数点以下になるほど共通ルールというよりも、かなり緩い感覚的な管理になっていきます。
このバージョン情報で一番話題になるのはAppleのiOSではないでしょうか。最近は革新的な新サービス・新機能が誕生することは少なくなりましたが、iPhone・iPadユーザーにとってOSのバージョンアップは常に興味のある話だと思います。そして、アプリ開発者にとってはアップデートにより何が起こるのか分からず、なかなかハラハラさせられる出来事でもありますね。
Appleはメジャーアップデートによる混乱を避けるために、開発者向けに正式版の前にアルファ版・ベータ版・ゴールデンマスター（GM）と呼ばれるリリース前のOSを段階的に提供しています。
今回は、そんな「バージョン表記」の一般的なルールについて、どのような意味・ルールがあるのかを解説したいと思います。当然、これは単なる「決めごと」なので会社やシステムによって異なります。
ソフトウェア（アプリケーション）のバージョン情報とは
一般的なバージョン情報は、ピリオド区切りで多くても4つくらいの数字（パート）で構成されています。小さな規模のシステムでは2つくらいに抑えられています。
先ほどの Google Chrome の場合、「69.0.3497.100」という4つの数字で構成されていましたが、この4つの数字には下記のような意味があります。
- Major（メジャー）
- Minor（マイナー）
- Build（ビルド）
- Revision（リビジョン）
これを基にすると、先ほどの Google Chrome 69.0.397.100 のバージョンは「メジャー 69」「マイナー 0」「ビルド 3497」「リビジョン 100」のバージョンであることが分かりますね。
iOSやAndroidが大きく変わるときに「メジャーアップデート」と言われるのは、一番最初に出てくる「Major（メジャー）」がバージョンアップされるときの話です。システム開発に携わったことのある人には馴染みがあると思いますが、エンドユーザーとしては「メジャー」以外は触れる機会のない言葉かも知れません。
それでは、それぞれの言葉の意味を確認していきましょう。
Major（メジャー）
最初の「Major（メジャー）」ですが、これは一番分かりやすいですね。アプリやシステムが初めて世の中にリリースされるときは、必ず1から始まります。まだ正式版ではない場合、バージョン0にしてテスト配布やパイロットユーザーを募っているようなこともありますね（iOSで言うTestFlightです）。
このメジャーバージョンは、下記のようなケースでアプリやシステムが大きく変わるときに数字が繰り上がります。
- 新しい技術や基準によりアーキテクチャに大きな変更があったとき
- 大きな機能追加や削除があったとき
- 用途や処理、UI（User Interface, ユーザーインターフェース）に変更があったとき
メジャーバージョンは、上記のような大きな変更・改修が入ったときに数字が繰り上がります。
Minor（マイナー）
次の「Minor（マイナー）」ですが、これは下記のような場合にバージョンアップされます。
- サービスパックをリリースしたとき（最初から完璧なソフトウェアは存在しないため）
- バグフィクスや特別な機能をサポートしたとき
マイナーのバージョンアップはメジャーほど大きくはない機能追加やバグフィクスがメインです。これはWindowsでも数字とアルファベットを組み合わせたバージョン情報として目にする人も多いと思います。
Build（ビルド）
Major, Minor に続く3番目にあるのは「Build（ビルド）」です。ここからは利用者側に見せないケースも出てくるパートですね。
これはシステム開発ライフサイクル（SDLC, Systems Development Life Cycle）において、ソフトウェアがどのポイントまで到達しているかを示します。通常、開発チームが採用するウォーターフォール・モデル、スパイラル・モデル、アジャイル、反復型などの開発モデルにおいては、実際の開発工程を分割してモジュールを完成させていきます。
一つの工程が完了してユーザーアクセプタンス（User Acceptance）やQAに進むたび、このBuildのバージョンは繰り上げることになります。要するに、開発工程が進むとBuildの数字が上がっていき、それがマイナーアップデートにつながるということですね。
Revision（リビジョン）
最後の 「Revision（リビジョン）」は3つ目の Build（ビルド）の改訂数を示します。
どのような開発チームも最初から完璧な開発（ビルド）を出せることはありません。そのため、バグの発生・発見やバグ修正を繰り返しながら開発を進めることになります。そして、そのビルドのための改修を繰り返すたびにリビジョンは繰り上がっていくことになります。
あくまでもバージョニングの一例です
冒頭にも書いたとおり、ご紹介したバージョニングの方法は一般的ではありますが、国際的に標準化されているようなルールもなくあくまでも一つの方法・考え方に過ぎません。
会社によってはメジャーとマイナーのバージョン管理のみであったり、大掛かりな開発でない場合はビルドまでの管理だったりします。さらには、ソフトウェアのバージョンをリリースした西暦にするような管理をする会社もあり、実務的には開発会社の文化に合せるという他はないでしょう。
また、コンシューマー向けのシステムの場合、開発のバージョン管理とエンドユーザーに見せるものが異なることもあります。分かりやすいように、ユーザー向けにはメジャーとマイナーまでを公開するようにしているわけですね。
今回の記事がシステム開発のバージョニングに関する一つの参考になれば幸いです。
参考：SOFTWARE VERSIONING AND RELEASE NUMBERS - Zapbuild
