検索
連載

意外と知らないバージョン表記・数字の豆知識：安藤幸央のランダウン（51）

「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします（編集部）

Share
Tweet
LINE
Hatena

ちまたにあふれるバージョン表記

　少し前に「Web 2.0」「○○2.0」という表記が流行したのを覚えていますでしょうか。よく見かける広告のコピーにも、最近では「バージョンアップ」という言葉が普通に使われています。バージョンや、バージョン表記は、ソフトウェアの世界だけでなく、ごくごく一般化したように思えます。しかし実際には、どういう意味か分からないのが、バージョン表記です。

　アプリケーションソフトウェアの開発は、さまざまな状態／段階を経て完成します。その段階／状態と、リリース後の状態／段階を示したのが、バージョン表記です。

　例えば、数字以外でも、以下のような表記を見かけたことはありませんか？

  • Pre-Alpha（Nightly Build）
  • Alpha
  • Beta
  • RC（Release Candidate）
  • RTM（Release to Manufacturing）または、GM（Golden Master）
  • GA（General Availability）

　一般ユーザー向けリリースの前にギリシャ文字の1文字目のα、2文字目のβを付けて開発版を表記するのが一般的です。

  • ギリシャ文字の1文字目、α（アルファ）＝開発の第1段階
  • ギリシャ文字の2文字目、β（ベータ）＝開発の第2段階

　その後、リリース候補版（RC）版となります。ごくまれに、RC版に相当するバージョンを「γ（ガンマ）」版と呼ぶこともあります。

　一般的には、最初のユーザー向けのリリースを「Stable（安定板）1.0」とし、そこから順番に1.1や2.0などと数字を付けることが多いです。

いまさら聞けない各バージョンの開発段階

　アルファやベータなどの意味について見てみましょう。

□Pre-Alpha版

　まだ予定している機能がすべて実装されていない段階のバージョンです。開発途中の毎晩ビルドされるテスト用のバージョンを示す場合もあります。

□Alpha（アルファ）版

　開発途中のバージョンです。特に開発の初期段階にあるものを指します。プロトタイプとして開発されたものは、含みません。

　未実装の機能や、未知の致命的な不具合が残っている場合もあります。動作が不安定であるという前提で開発者やテスト担当者が利用するものです。

□Beta（ベータ）版

　予定していた機能が一通り正常に動作する状態です。想定外の不具合や異常終了があるかもしれません。公式リリース前に一部のユーザーや開発メンバー周辺向けにテスト公開するくらいの出来のものです。

　アプリケーションのクラッシュやデータ損失、速度の遅さなどのリスクもあり、既知のバグがまだ残っている可能性があります。アルファ版で不安定過ぎる機能は、ベータ版では機能が停止されているような場合もあります。

□Public Beta（パブリックベータ）版

　一般に広く公開してバグ報告を受けるのを主な目的とするバージョンです。ベータ版を一部のユーザーに試用してもらい、不具合の洗い出し、機能要望などを聞き出すためにあります。

　また、製品版になる前にユーザーを獲得するための手段として期間限定で無料配布するような場合もあります。

□RC（Release Candidate）版

　リリース候補版のことです。致命的なバグがないかぎり、このバージョンがリリースされる予定となります。十分なテストが完了し、特に大きな不具合がなければ、このバージョンと同じものが、正式版となります。

　RC版の段階で重大な不具合が見つかり修正された場合は、RC2、RC3……とカウントアップする場合もあります。

□RTM（Release to Manufacturing）版

　出荷版です。パッケージアプリケーションの場合、このバージョンがCD-ROMやDVD-ROMになって出荷されます。最終版をマスタとして複製がたくさん作られることから「Golden Master」と呼ぶこともあります。

□GA（General Availability）版

　一般ユーザーが入手可能なバージョンです。

□開発スタイルや開発手法の違いで変わる

　以上は、あくまで一般的な印象です。開発スタイルや開発手法の違いによって、バージョンの付け方が微妙に異なる場合もあります。

　例えば、昨今のWebアプリケーションのように、ベータ版の状態で多くのユーザーを集めて運用開始する例もありますが、それについては後ほど触れます。

バージョン表記の数字の意味、分かっていますか？

　バージョン表記といえば、数字で表しているものも良く見かけます。例えば、Webブラウザ「Google Chrome」のバージョン表記は、どう読み取ればよいのでしょうか？

　2010年3月の原稿執筆時現在で最新版に更新すると、「Google Chrome 5.0.307.11 beta」と表記されています。以下、数字を細かく見ると、以下のように分類できます。

  • 5：メジャーバージョン
  • 0：マイナーバージョン。この場合は、バージョン5の最初のもの
  • 307：累積バージョン。ビルドバージョン。Chromeが出てから307番目に作られたもの
  • 11：累積バージョンのマイナー番号（子番号）。リビジョン（修正版）

　また、数字のほかに、文言も追加されています。

  • Stable：安定版。より多くのテストがなされ、一般に安定して使えるもの
  • Beta：ベータ版。新しい機能をより早く試してみたい人向け。多少不安定な場合もあり
  • Dev：開発版。開発者向けのプレビュー版

　さまざまなバージョンが存在するので、どれが一番新しいものか、パッと見にはなかなか分かりにくい面があります。一般的には安定版を利用し、自身でリスクを認識したうえで、新しい機能を試したり、速度向上などを期待してBeta版やDev版を試してみるといいでしょう。

　単にユーザーとして利用する場合は、アプリケーションの自動アップデート機能に頼るのも安心する方法の1つです。

　そのほか、「○○2003」「○○2008」など、年号でバージョン表記するものもあります。年号をバージョン表記に用いた場合、リリースされた時期は最新版であることがすぐ分かりますが、その年を過ぎてしまうと、「古いバージョンである」という印象が強くなります。

マーケティング戦略に左右されるバージョン表記

　バージョン番号は単に開発する側の都合だけではなく、マーケティングの要素が強く影響して付けられる場合もあります。

　例えば競合製品があった場合、競合製品よりも大きいバージョン番号が付いていた方がより新しい、より高機能なバージョンだと思ってもらえるたりなど、さまざまな理由があるようです。内部的なバージョン表記と対外的なバージョン表記が異なる場合も多々あります。

  • Visual Studio 2005（内部バージョンは8.0）
  • Visual Studio 2008（内部バージョンは9.0）
  • Windows XPの内部バージョンは5.1.2600
  • Google Android 1.5（内部バージョンはAPI Level 3)
  • Google Android 1.6（内部バージョンはAPI Level 4)

　また、単純に日付けをバージョン番号にしてしまう表記方法もあります。

  • 楽天 API ver.2009-10-20

　Javaのバージョン番号も歴史的に見て、右往左往したものの1つでしょう。

  • JDK 1.1.X
  • J2SDK
  • J2SE 1.2
  • J2SE 1.3
  • J2SE 1.4
  • J2SE 1.5
  • J2SE 5.0
  • Java SE 5
  • Java SE 6
  • Java SE 7
  • ……

　Linux OSの特定のバージョンなど、オープンソースの世界で標準的な手法としては、バージョンが奇数のものは開発版、偶数のものが安定版といった暗黙の了解として扱われているものもあります。

　Perl周辺では、バージョン番号は数字のみで表記するのが、一般的なルールとなっています。alpha（α）やbeta（β）、RCなどは、共通の書き方がなく、いろいろな解釈がされてしまうため、避けられています。

　iPhoneアプリを開発して登録する際、1.01の次に、1.1は登録できず、1.10となります。内部バージョンと、App Storeに表記されるバージョンをうまく管理するよう気を付けなければいけません。

「バージョン」をアップするときのワナ

　頻繁にバージョンアップ（アップグレード）するソフトウェアで、下位互換／上位互換を気にする場合は、バージョン同士の比較に間違いがないことも重要な要素です。

　Windows 95の次が98、その次がMEや2000、単純な数字の比較では変なことになります。

　また、下記のように数字の後のピリオドの付け方でバージョンがまったく異なる場合もあるので、注意が必要です。

  • ver. 1.2.34567 ≠ ver. 1.00234567
  • ver. 1.00234567 ≠ ver. 1.2.345.670

　また、ソフトウェアによっては複数のバージョンが共存できないものも、共存できるものもあるので、扱いに注意が必要です。

「永遠のベータ」で良いのか？

　Webサービスやクラウド・コンピューティング環境のサービス（SaaSなど）の場合、どこかで「完成版」となるわけではなく、ユーザーがあまり意識しないところでバグ修正やアプリケーションのバージョンアップが続けられていきます（参考：Google Appsは常に「バージョン・ベスト」、米グーグル副社長）。

　「Web 2.0」が流行した際には「永遠のベータ（Perpetual Beta）」と呼ばれ、「これぞWeb 2.0の醍醐味」という感じで、興味深く迎えられました。ベータ版の状態で多くのユーザーを集めて運用開始する例もあります。

　しかし、誰も不完全なものを喜んで利用したいわけではありません。37signals社のように、「ベンチャー企業がユーザーに信頼して使ってもらえるサービスをローンチする際は、「ベータ」といって責任逃れをしてはいけない」という確固たる考えを持つ場合もあります。

　開発リソースが足りないとき、ベータ版として中途半端なサービスではなく、必要な機能のみに力を注いだ「半分」に完成度を高めたサービスを使ってもらうのです。

　変更や修正が容易なWebサービスで新機能を加えたベータ版の提供を考えていたとしましょう。その際、ベータ版として新しいバージョンを分けるのではなく、既存のサービスにベータ版の機能を追加するのです。

　特定のヘビーユーザーには、先に使える権利を与えるのも良い方法です。そうして親しみを持って使ってもらえるユーザーに、開発の重要メンバーとして加わってもらい、機能要望を聞き入れたり、細かなバグの発見に協力してもらうのです。

　さらに携帯電話用、iPhoneやスマートフォン用のアプリケーションであれば、一度インストールされて使い始めると、なかなかバージョンアップをしてもらえないといったことも考慮しておかなければいけません。

　バージョンアップの際には、それまで使っていたデータを保護したり、継続して使えるようにベータ版で利用したデータも正式版へ移行する手だても考えておかなければいけません。ソフトウェアのサスティナビリティ（持続可能性）も重要な要素となってくることでしょう。

　次回は、2010年5月初めごろに公開の予定です。内容は未定ですが、読者の皆さんの興味を引き、役立つ記事にする予定です。何か取り上げてほしい内容などリクエストがありましたら、編集部や＠ITの掲示板までお知らせください。次回もどうぞよろしく。

プロフィール

安藤幸央（あんどう ゆきお）

安藤幸央

1970年北海道生まれ。現在、株式会社エクサ マルチメディアソリューションセンター所属。フォトリアリスティック3次元コンピュータグラフィックス、リアルタイムグラフィックスやネットワークを利用した各種開発業務に携わる。コンピュータ自動彩色システムや3次元イメージ検索システム大規模データ可視化システム、リアルタイムCG投影システム、建築業界、エンターテインメント向け3次元 CG ソフトの開発、インターネットベースのコンピュータグラフィックスシステムなどを手掛ける。また、Java、Web3D、OpenGL、3DCG の情報源となるWebページをまとめている。

ホームページ
Java News.jp（Javaに関する最新ニュース）

所属団体
OpenGL_Japan (Member)、SIGGRAPH TOKYO (Vice Chairman)

主な著書
「VRML 60分ガイド」（監訳、ソフトバンク）
「これがJava だ! インターネットの新たな主役」（共著、日本経済新聞社）
「The Java3D API仕様」（監修、アスキー）


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る