ソフトウェアのバージョン管理

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェアのバージョン管理は、コンピュータソフトウェアの一意の状態に一意のバージョン名または一意のバージョン番号を割り当てるプロセスです。特定のバージョン番号カテゴリ(メジャーまたはマイナーなど)内では、これらの番号は通常、昇順で割り当てられ、ソフトウェアの新しい開発に対応します。きめ細かいレベルでは、リビジョン管理は、情報がコンピュータソフトウェアであるかどうかに関係なく、段階的に異なるバージョンの情報を追跡するためによく使用されます。

最近のコンピューターソフトウェアは、2つの異なるソフトウェアバージョニングスキームを使用して追跡されることがよくあります。リビジョン管理番号など、1日に何度もインクリメントされる可能性のある内部バージョン番号と、セマンティックバージョニングなどの通常ははるかに少ない頻度で変更されるリリースバージョンです。 [1]またはプロジェクトコード名

スキーム

ソフトウェアのさまざまなバージョンを追跡するために、さまざまなバージョン番号付けスキームが作成されています。コンピュータの普及により、これらのスキームはコンピューティング以外のコンテキストで使用されるようになりました。

シーケンスベースの識別子

バージョン番号シーケンス

シーケンスベースのソフトウェアバージョン管理スキームでは、各ソフトウェアリリースには、数字または文字の1つ以上のシーケンスで構成される一意の識別子が割り当てられます。これは共通性の範囲です。スキームは、シーケンスの数、個々のシーケンスへの意味の帰属、シーケンスをインクリメントする手段などの領域で大きく異なります。

重要性を変える

一部のスキームでは、リリース間の変更の重要性を伝えるためにシーケンスベースの識別子が使用されます。変更は有意水準によって分類され、リリース間で変更するシーケンスの決定は、前のリリースからの変更の重要性に基づいて行われます。これにより、最初のシーケンスが最も重要な変更に対して変更され、最初のシーケンスの後の変更が重要性が低下する変化。

スキームによっては、重要性は、コード行の変更、ファンクションポイントの追加または削除、新しいバージョンの採用に必要な作業に関する顧客への潜在的な影響、バグまたは宣言されていない重大な変更のリスク、ビジュアルの変更の程度によって評価される場合があります。レイアウト、新機能の数、または製品開発者やマーケターが重要と見なすほとんどすべてのもの。これには、新しいバージョンの「相対的な良さ」を強調したいというマーケティングの欲求が含まれます。

セマンティックバージョニングの3部構成のバージョン番号

セマンティックバージョニング(別名SemVer)、 [1]は、広く採用されているバージョンスキーム[2]です。これは、3つの部分からなるバージョン番号(Major.Minor.Patch)、オプションのプレリリースタグ、およびオプションのビルドメタタグを使用します。このスキームでは、リスクと機能が重要性の尺度です。重大な変化は、メジャー数を増やすことで示されます(リスクが高い)。新しい、壊れない機能は、マイナー数をインクリメントします(中リスク)。他のすべての非破壊的な変更は、パッチ番号をインクリメントします(リスクが最も低い)。プレリリースタグ(-alpha、-beta)の存在は、実質的なリスクを示します。ゼロ(0.yz)のメジャー数は、潜在的に任意のレベルを含む可能性のある進行中の作業を示すために使用されます。重大な変更(最も高いリスク)。SemVerバージョンから互換性を推測する例として、APIのバージョン2.1.5に依存するソフトウェアは、バージョン2.2.3と互換性がありますが、必ずしも3.2.4と互換性があるとは限りません。

開発者は、重要な機能が追加されたことを示すために一度に複数のマイナーバージョンをジャンプすることを選択できますが、メジャーバージョン番号を増やすことを保証するのに十分ではありません。たとえば、5.1から5.5までのInternet Explorer 5、または5.1から5.5までのAdobe Photoshop5です。これは、ソフトウェアユーザーへのアップグレードの価値を強調するため、またはAdobeの場合のように、メジャーバージョンの中間のリリースを表すために行うことができます(ただし、Blenderのように、シーケンスベースのバージョン管理のレベルは必ずしも1桁に制限されません)バージョン2.91または1.10以降のMinecraftJava Edition)。

別のアプローチは、リリースタイプを示す英数字の文字列(「アルファ」(a)、「ベータ」(b)、「リリース候補」(rc)など)とともに、メジャー番号とマイナー番号を使用することです。このアプローチを使用するソフトウェアリリーストレインは、0.5、0.6、0.7、0.8、0.9→1.0b1、1.0b2(いくつかの修正あり)、1.0b3(より多くの修正あり)→1.0rc1(十分に安定している場合)のようになります。 、1.0rc2(さらにバグが見つかった場合)→1.0。このスキームでは、リリース候補フェーズ中に新機能と重大な変更をロックアウトするのが一般的です。一部のチームでは、ターゲットリリースへの収束を確実にするために、ベータ版でさえバグ修正のみにロックダウンされます。

他のスキームは、個々のシーケンスに意味を与えます。

major.minor [.build [.revision]] (例:1.2.12.102
major.minor [.maintenance [.build]] (例:1.4.3.5249

繰り返しますが、これらの例では、「マイナー」な変更ではなく「メジャー」を構成するものの定義は完全に主観的であり、「ビルド」を定義するもの、または「リビジョン」が"少しの変化。

SolarisおよびLinuxの共有ライブラリは、 current.revision.age形式を使用する場合があります。 [3] [4]

current:ライブラリが実装する最新のインターフェース番号。
リビジョン:現在のインターフェースの実装番号。
年齢:ライブラリが実装する最新のインターフェイスと最も古いインターフェイスの違い。この3番目のフィールドの使用は、 libtoolに固有です。他のフィールドは、異なる意味を使用するか、単に無視する場合があります。

相対的な変化の重要性とバージョン管理の命名法の同様の問題は、さまざまな基準に基づいて エディション番号または名前を選択できる本の出版にも存在します。

ほとんどのプロプライエタリソフトウェアでは、ソフトウェア製品の最初にリリースされたバージョンにはバージョン1があります。[要出典]

互換性の程度

一部のプロジェクトでは、メジャーバージョン番号を使用して互換性のないリリースを示しています。2つの例は、Apache Portable Runtime(APR)[5]とFarCryCMSです。[6]

多くの場合、プログラマーは下位互換性のある新しいソフトウェアを作成します。つまり、新しいソフトウェアは、古いバージョンのソフトウェア(古いプロトコルとファイル形式を使用)および最新バージョン(最新のプロトコルとファイル形式を使用)と正しく対話するように設計されています。たとえば、IBM z / OSは、同じシスプレックスで実行されているオペレーティングシステムの3つの連続するメジャーバージョンで正しく動作するように設計されています。これにより、高可用性コンピュータークラスターを実行しているユーザーは、一度に1台のコンピューターをシャットダウン、アップグレード、およびサービスに復元している間、ほとんどのコンピューターを稼働状態に保つことができます。[7]

多くの場合、パケットヘッダーファイル形式にはバージョン番号が含まれています。これは、それを作成したソフトウェアのバージョン番号と同じ場合もあります。また、ソフトウェアのバージョン番号に依存しない「プロトコルのバージョン番号」もあります。古い非推奨のプロトコルとファイル形式を処理するためのコードは、多くの場合、くだらないものと見なされます。

開発段階の指定

実験段階(アルファまたはベータ)のソフトウェアは、多くの場合、シーケンスの最初の(「メジャー」)位置にゼロを使用して、そのステータスを指定します。ただし、このスキームは初期段階でのみ有用であり、バージョン番号がすでに0を超えて進行している確立されたソフトウェアを使用した今後のリリースには役立ちません。[1]

新しいリリースのステータスを示すために、いくつかのスキームが使用されます。

  • 英数字の接尾辞は、セマンティックバージョニングで採用されている一般的なスキームです。[1]このスキームでは、バージョンには、ステータスを示すためにダッシュといくつかの英数字が付加されています。
  • 数値ステータスは、シーケンスの一部であるかのようにステータスを示すために数字を使用するスキームです。典型的な選択は、4ポジションバージョンの3番目のポジションです。
  • 数値90+は数値を使用する別のスキームですが、明らかに以前のバージョンの数値の下にあります。最後の位置にある多数(通常は90以上)が使用されます。これは、 Fontconfigなどの古いオープンソースプロジェクトで一般的に使用されています
開発段階の指標の比較
ステージ Semver スターテス 番号90+
アルファ 1.2.0-a.1 1.2.0.1 1.1.90
ベータ 1.2.0-b.2 1.2.1.2 1.1.93
リリース候補版 1.2.0-rc.3 1.2.2.3 1.1.97
リリース 1.2.0 1.2.3.0 1.2.0
リリース後の修正 1.2.5 1.2.3.5 1.2.5

2つの純粋な数値形式は、セマンティックバージョニングで見られる「アルファ<ベータ<rc <プレフィックスなし」の比較を処理するために必要な特別なロジックを削除しますが、明確さを犠牲にします。(セマンティックバージョニングは、実際には開発段階の特定の用語を指定していません。比較は単に辞書式順序で行われます。)

インクリメントシーケンス

数値バージョン番号がどのようにインクリメントされるかについては、2つの考え方があります。MediaWikiを含むほとんどの無料のオープンソースソフトウェアパッケージは、バージョンをピリオドで区切られた一連の個別の数字として扱い、1.7.0、1.8.0、1.8.1、1.9.0、1.10.0、 1.11.0、1.11.1、1.11.2など。

一方、一部のソフトウェアパッケージは、リリースを10進数で識別します:1.7、1.8、1.81、1.82、1.9など。10進数バージョンは、1980年代、たとえばNetWareDOSMicrosoft Windowsで一般的でしたが、2000年代でも一般的でした。たとえば、Opera [8]MovableTypeで使用されています。[9] 10進法では、1.81は1.8に続くマイナーバージョンですが、メンテナンスリリース(つまりバグ修正のみ)は、1.81aや1.81bなどのアルファベットのサフィックスで示される場合があります。

標準のGNUバージョン番号付けスキームはmajor.minor.revision [10]ですが、Emacsは、メジャー番号(1)が削除され、ユーザーサイトのリビジョンが追加された別のスキームを使用した注目すべき例です。ディストリビューターによって増加しました。[11]同様に、Debianパッケージ番号の前にはオプションの「エポック」が付いています。これは、バージョン管理スキームを変更できるようにするために使用されます。[12]

リセット

場合によっては、開発者はメジャーバージョン番号をリセットすることを決定することがあります。これは、リリースされる新しい開発フェーズを示すために使用されることがあります。たとえば、Minecraft Alphaはバージョン1.0.0から1.2.6まで実行され、Betaがリリースされると、メジャーバージョン番号がリセットされて1.0から1.8まで実行されました。ゲームが完全にリリースされると、メジャーバージョン番号は再び1.0.0にリセットされます。[13]

シーケンスの分離

印刷時に、シーケンスを文字で区切ることができます。文字の選択とその使用法は、スキームによって異なります。次のリストは、同じリリース(13番目の3番目のレベルのリビジョンから4番目の2番目のレベルのリビジョンから2番目の1番目のレベルのリビジョン)の分離スキームの仮想的な例を示しています]

  • スキームは、すべてのシーケンス間で同じ文字を使用できます:2.4.13、2 / 4 / 13、2-4-13
  • 分離するシーケンスの選択が一貫していない可能性があり、一部のシーケンスは分離されますが、他のシーケンスは分離されません:2.413
  • スキームの文字の選択は、同じ識別子内で一貫していない可能性があります:2.4_13

ピリオドを使用してシーケンスを区切る場合、小数点を表す場合とそうでない場合がありますさまざまな解釈スタイル については、「シーケンスのインクリメント」セクションを参照してください。

シーケンスの数

( Microsoftが使用している)ソフトウェアビルドを示す4番目の未公開の番号が存在する場合がありますAdobe Flashは、10.1.53.64のように、4つの部分からなるバージョン番号が公開されている注目すべきケースです。一部の企業には、ビルド日も含まれています。バージョン番号には、文字やLotus1-2-3リリース1a などの他の文字が含まれる場合もあります。

負の数

一部のプロジェクトでは、負のバージョン番号を使用しています。1つの例は、-1.0から開始して0.0までカウントアップしたSmartEiffelコンパイラです。[11]

リリース日

CalVer 形式でリリース番号を表示するStreetFighterEXスプラッシュ画面

多くのプロジェクトでは、 Calendar Versioning(別名CalVer [14] )と呼ばれる日付ベースのバージョン管理スキームを使用しています

Ubuntu Linuxは、カレンダーのバージョン管理を使用するプロジェクトの一例です。たとえば、Ubuntu 18.04は2018年4月にリリースされました。これには、開発スケジュールとサポートタイムラインに簡単に関連付けることができるという利点があります。アーケードゲームの ストリートファイターEXなど、一部のビデオゲームではバージョン管理として日付も使用されます起動時に、バージョン番号を日付とリージョンコード(例:961219 ASIA )として表示します。[要出典]

ファイル名などのバージョン管理で日付を使用する場合は、ISO8601スキーム[15] YYYY-MM-DDを使用するのが一般的です。これは、昇順または降順で簡単に文字列を並べ替えることができるためです。ハイフンは省略される場合があります。Wineプロジェクトは、以前は日付バージョン管理スキームを使用していました。これは、年、月、リリース日を使用していました。たとえば、「Wine20040505」。[要出典]

Microsoft Officeのビルド番号はエンコードされた日付です。[16]最初の2桁は、プロジェクトが開始された年の1月から経過した月数を示します(Officeのメジャーリリースはそれぞれ異なるプロジェクトです)。 2桁の数字は、その月の日を示します。したがって、3419は、プロジェクトが開始された年の1月から34か月目の19日目です。[要出典]

年ごとにバージョンを識別する他の例には、Adobe Illustrator88およびWordPerfectOffice 2003が含まれます。年がバージョンを表すために使用される場合、それは一般にマーケティング目的であり、実際のバージョン番号も存在​​します。たとえば、Microsoft Windows95は内部でMS-DOS7.00およびWindows4.00としてバージョン管理されています。同様に、Microsoft Windows 2000 Serverは、内部的にWindows NT 5.0としてバージョン管理されています(「NT」は元の製品名への参照です)。独自の研究?]

Python

Python SoftwareFoundationPEP440 –バージョンの識別と依存関係の仕様[17]を公開しました。これは、エポックセグメント、リリースセグメント、プレリリースとポストリリースのセグメント、および開発リリースのセグメントを定義する独自の柔軟なスキームの概要を示しています。

TeX

TeXには、特異なバージョン番号付けシステムがあります。バージョン3以降、更新は末尾に数字を追加することで示されるため、バージョン番号は漸近的にπに近づきます。単項ナンバリングの形式–バージョン番号は桁数です。現在のバージョンは3.14159265です。これは、TeXが非常に安定していることを反映しており、マイナーな更新のみが予想されます。TeX開発者のDonaldKnuthは、「絶対に最終的な変更([彼の]死後に行われる)」はバージョン番号をπに変更することであり、その時点で残りのすべてのバグが永続的な機能になると述べています。[18]

同様に、 Metafontのバージョン番号は漸近的にeに近づきます。

アップル

クラシックMacOSの時代には、マイナーバージョン番号が「.1」を超えることはめったにありませんでした。彼らがそうしたとき、彼らは通常「.5」にまっすぐにジャンプし、リリースが「より重要」であったことを示唆しました。[a]したがって、「8.5」は「Mac OS 8半」を表す独自のリリースとして販売され、8.6は事実上「8.5.1」を意味していました。

Mac OS Xは、主に「X」(10のローマ数字)が製品の名前に含まれていたため、この傾向から逸脱しました。その結果、OS Xのすべてのバージョンは番号10で始まりました。OSXの最初のメジャーリリースにはバージョン番号10.0が付けられましたが、次のメジャーリリースは11.0ではありませんでした。代わりに、10.1の番号が付けられ、その後のメジャーリリースごとに10.2、10.3などが続きます。したがって、OSXの11番目のメジャーバージョンには「10.10」というラベルが付けられました。「X」はmacOS10.12の時点で名前から削除されましたが、この番号付けスキームはmacOS10.15まで続きました。「X」ベースのバージョン管理スキームでは、3番目の番号(2番目ではなく)はマイナーリリース、このレベルより下の追加の更新、および新しいリリース後に提供されるOSXの特定のメジャーバージョンへの更新を示します。メジャーバージョンは、SupplementalUpdatesというタイトルでした。[19]

ローマ数字のXは、複数の製品ラインにわたるマーケティング目的で同時に活用されました。QuickTimeFinalCut Proはどちらもバージョン7からバージョン10に直接ジャンプし、QuickTimeXとFinalCut ProXです。MacOSX自体と同様に、製品は以前のバージョンへのアップグレードではなく、まったく新しいプログラムでした。OS Xと同様に、これらのプログラムのメジャーリリースは2桁目を増やし、マイナーリリースは3桁目を使用して示されていました。「X」はmacOS11.0のリリースでFinalCutの名前から削除され(以下を参照)、2011年にフレームワークがAVFoundationを支持して廃止されたとき、QuickTimeのブランディングは無意味になりました(QuickTimeビデオを再生するためのプログラムは開始)。

Appleの次のmacOSリリース(暫定番号10.16、[20])は、2020年6月にWWDCでmacOS 11.0として正式に発表されました。[21]次のmacOSバージョン、macOSMontereyはWWDC2021でリリースされ、メジャーバージョン番号を12に上げました。[22 ]

Microsoft Windows

Microsoft Windowsオペレーティングシステムは、最初にWindows1.0からWindows3.11標準バージョン番号でラベル付けされましたこの後、Microsoftは製品名からバージョン番号を除外しました。Windows 95(バージョン4.0)、Windows 98(4.10)、およびWindows 2000 (5.0)の場合、リリース年が製品タイトルに含まれていました。Windows 2000の後、MicrosoftはWindows Serverファミリを作成しました。これは、年ベースのスタイルを継続して変更しました。マイナーリリースの場合、Microsoftはタイトルに「R2」の接尾辞を付けました(例:Windows Server 2008 R2 )。(バージョン6.1)。このスタイルは、この日付まで一貫していました。ただし、Windowsのクライアントバージョンは一貫したスタイルを採用していませんでした。まず、 Windows ME(4.90)、Windows XP(5.1)、およびWindows Vista(6.0)と同様に、任意の英数字のサフィックスが付いた名前を受け取りました。次に、Microsoftは再びタイトルに増分番号を採用しましたが、今回はバージョン番号ではありませんでした。Windows 7Windows 8、およびWindows 8.1のバージョン番号は、それぞれ6.1、6.2、および6.3です。Windows 10では、バージョン番号が10.0 [23]に跳ね上がり、その後OSが更新されました。増分されたビルド番号と更新ビルドリビジョン(UBR)番号のみ。

Windows 10の後継であるWindows11は、2021年10月5日にリリースされました。「11」という名前が付けられたにもかかわらず、新しいWindowsリリースはメジャーバージョン番号を11に上げませんでした。代わりに、同じバージョン番号10.0のままでした。 、Windows10で使用されます。[24]

その他のスキーム

一部のソフトウェアプロデューサーは、ソフトウェアのリリースを示すために異なるスキームを使用しています。Debianプロジェクトは、オペレーティングシステムのリリースにメジャー/マイナーバージョン管理スキームを使用しますが、開発中に映画トイストーリーのコード名を使用して、安定した、不安定な、テスト中のリリースを参照します。[25]

BLAG LinuxおよびGNUは、非常に大きなバージョン番号を備えています。メジャーリリースには50000や60000などの番号がありますが、マイナーリリースでは番号が1つ増えます(例:50001、50002)。アルファリリースとベータリリースには、メジャーリリース番号よりもわずかに小さい10進数のバージョン番号が付けられます。たとえば、バージョン20000のアルファ1の場合は19999.00071、バージョン30000のベータ2の場合は29999.50000です。2003年の9001から、2011年の最新バージョンは140000。[26] [27] [28]

Urbitケルビンバージョン管理(絶対ケルビン温度スケールにちなんで名付けられました)を使用します。ソフトウェアバージョンは高い数値から始まり、バージョン0までカウントダウンします。この時点で、ソフトウェアは終了したと見なされ、それ以上の変更は行われません。[29] [30]

内部バージョン番号

ソフトウェアには、製品名に示されているバージョン番号とは異なる「内部」バージョン番号が付いている場合があります(通常、バージョン番号の規則に一貫して準拠しています)。たとえば、Java SE 5.0の内部バージョン番号は1.5.0であり、NT 4以降のWindowsのバージョンは、標準の数値バージョンを内部的に継続しています。Windows2000はNT 5.0、XPはWindows NT 5.1、Windows Server 2003、およびWindowsです。 XP Professional x64EditionはNT5.2、Windows Server2008およびVistaはNT6.0、Windows Server 2008R2およびWindows7はNT6.1、Windows Server2012およびWindows8はNT6.2、およびWindows Server 2012R2およびWindows8.1はNT6.3ですが、Windows 10の最初のバージョンは10.0(10.0.10240)でした。ただし、Windows NTは5番目のメジャーリビジョンにすぎないことに注意してください。最初のリリースの番号は3.1(当時のWindowsリリース番号と一致するため)であり、Windows10のリリースによりバージョンが6.3から10.0に跳ね上がりました。

プレリリースバージョン

上記のさまざまなバージョン管理スキームと組み合わせて、プログラムがソフトウェアリリースライフサイクルの段階を通過するときに、プレリリースバージョンを示すシステムが一般的に使用されます

初期段階にあるプログラムは、ギリシャ文字の最初の文字にちなんで「アルファ」ソフトウェアと呼ばれることがよくあります。それらが成熟した後、まだリリースの準備ができていない場合、ギリシャ語のアルファベットの2番目の文字にちなんで、「ベータ」ソフトウェアと呼ばれることがあります。通常、アルファソフトウェアは開発者のみがテストしますが、ベータソフトウェアはコミュニティテスト用に配布されます。

一部のシステムは、最終的な「1.0」リリースに向けたアプローチを提案するために、1未満の数値バージョン(0.9など)を使用します。これは、オープンソースソフトウェアの一般的な規則です。[31] [32]ただし、プレリリースバージョンが既存のソフトウェアパッケージ用である場合(バージョン2.5など)、バージョン番号に「a」または「alpha」を追加できます。したがって、2.5リリースのアルファバージョンは2.5aまたは2.5.aとして識別される可能性があります。

別の方法として、プレリリースバージョンを「リリース候補」と呼び、特定のバージョンとして間もなくリリースされるソフトウェアパッケージに、リリース候補の番号を示す「rc-#」が後に続くバージョンタグを付けることができます。 ; 最終バージョンがリリースされると、「rc」タグが削除されます。

列車を解放する

ソフトウェアリリーストレインは、ソフトウェアリリーススケジュールの形式であり、複数の製品のバージョン化されたソフトウェアリリースのいくつかの異なるシリーズが、定期的なスケジュールでいくつかの異なる「トレイン」としてリリースされます。一般に、製品ラインごとに、さまざまなリリーストレインが特定の時間に実行され、各トレインは計画されたスケジュールで初期リリースから最終的な満期および引退に移行します。ユーザーは、新しいリリーストレインを本番環境に採用する前に実験することができます。これにより、新しいリリーストレインに移行する前に、本番システムの前のトレインのポイントリリースを引き続きフォローしながら、新しい「生の」リリースを早期に試すことができます。成熟します。

シスコのIOSソフトウェアプラットフォームは、何年にもわたって多くの異なるトレインを使用したリリーストレインスケジュールを使用していました。最近では、FirefoxやFenix for Android、[33] Eclipse[34] LibreOffice[35] Ubuntu[36] Fedora、[37] Python、[38] digiKam [39]VMware [ 39]などの他のプラットフォームも多数あります。 40]リリーストレインモデルを採用しています。

数値システムの変更

開発リリースの奇数バージョン

1.0シリーズと2.6.xシリーズの間で、Linuxカーネル奇数のマイナーバージョン番号を使用して開発リリースを示し、偶数のマイナーバージョン番号を使用して安定したリリースを示しました。Linuxカーネル§バージョン番号を参照してくださいたとえば、Linux 2.3はLinuxカーネルの2番目の主要な設計の開発ファミリであり、Linux2.4はLinux2.3が成熟した安定したリリースファミリでした。Linuxカーネルのマイナーバージョン番号の後には、昇順のリリース番号があります。たとえば、Linux2.4.0→Linux2.4.22です。2.6カーネルの2004リリース以降、Linuxはこのシステムを使用しなくなり、リリースサイクルが大幅に短縮されました。

同じ奇数偶数システムは、バージョン0.12までのNode.js 、GNOME、 WineHQなど、リリースサイクルが長い他のソフトウェアでも使用されています。[41]

最も重要な要素を削除する

SunのJavaには、内部バージョン番号が常に1であるハイブリッドシステムが使用されることがありました。xですが、xのみ 参照して販売されています。

  • JDK 1.0.3
  • JDK1.1.2から1.1.8
  • J2SE 1.2.0( "Java 2")から1.4.2
  • Java 1.5.0、1.6.0、1.7.0、1.8.0( "Java 5、6、7、8")

Sunはまた、Solarisの最初の桁を削除しました。Solaris2.8(または2.9)は、マーケティング資料ではSolaris 8(または9)と呼ばれています。

同様のジャンプが2010年代初頭にAsteriskオープンソースPBX構築キットで行われ、そのプロジェクトリーダーは、現在のバージョン1.8.xの後にバージョン10がまもなく続くと発表しました。[42]

このアプローチは、バージョン番号のセクションのセマンティックな重要性を損なうために多くの人に支持されており、MozillaFirefox用)を含むますます多くのベンダーによって採用されています。

バージョン番号注文システム

バージョン番号は、単純な整数(1、2、...)から有理数(2.08、2.09、2.10)に、そして4:3.4.3-2などの非数値の「番号」に非常にすばやく進化します。したがって、これらの複雑なバージョン番号は、文字列としてより適切に扱われます。パッケージ管理機能を含むオペレーティングシステム(重要なLinuxまたはBSDディストリビューションなど)は、さまざまなソフトウェアパッケージのバージョン番号を比較するためにディストリビューション固有のアルゴリズムを使用します。たとえば、Red Hatおよび派生ディストリビューションの順序付けアルゴリズムは、Debianのようなディストリビューションの順序付けアルゴリズムとは異なります。

驚くべきバージョン番号の順序付けの実装動作の例として、Debianでは、先行ゼロはチャンクで無視されるため、5.0005と5.5は等しく、5.5  <  5.0006と見なされます。これはユーザーを混乱させる可能性があります。文字列照合ツールは、特定のバージョン番号を見つけられない場合があります。プログラマーがバージョン番号インデックス付きハッシュテーブルなどの文字列インデックス付きデータ構造を使用する場合、これによりパッケージ管理に微妙なバグが発生する可能性があります

ソートを容易にするために、一部のソフトウェアパッケージは、major.minor.releaseスキームの各コンポーネントを固定幅で表します。Perlは、そのバージョン番号を浮動小数点数として表します。たとえば、Perlの5.8.7リリースは5.008007として表すこともできます。これにより、5.8.10の理論バージョンを5.008010として表すことができます。他のソフトウェアパッケージは、各セグメントを固定ビット幅にパックします。たとえば、Microsoft Windowsでは、バージョン番号6.3.9600.16384は16進数の0x0006000325804000として表されます。バージョン番号のいずれかのセグメントが999を超えると、浮動小数点スキームは機能しなくなります。1個あたり16ビットを使用するパックドバイナリ方式は、65535以降で機能しなくなります。

バージョン番号の政治的および文化的重要性

マイルストーンとしてのバージョン1.0

フリーソフトウェアオープンソースのコミュニティは、ソフトウェアを早期にリリースする傾向があります。初期バージョンは1未満の番号であり、これらの0.xバージョンは、ソフトウェアが不完全であり、一般リリースには十分な信頼性がないか、現在の状態で使用できないことを伝えるために使用されます。後方互換性のない変更は、0.xバージョンで一般的です。バージョン1.0は主要なマイルストーンとして使用され、ソフトウェアが少なくともすべての主要な機能に加えて、開発者がそのバージョンに取り入れたい機能を備えており、一般リリースに十分な信頼性があると見なされていることを示します。[31] [32]この良い例は、1991年にバージョン0.01として最初にリリースされたLinuxカーネルです[43]。1994年までバージョン1.0.0に到達するのにかかりました。[44]

アーケードゲームエミュレーターMAMEの開発者は、プログラムのバージョン1.0をリリースするつもりはありません。これは、エミュレートするアーケードゲームが常に増え、プロジェクトを完全に完了することができないためです。したがって、バージョン0.99の後にバージョン0.100が続きました。[45]

インターネットが普及したため、ほとんどの商用ソフトウェアベンダーは、メジャーバージョンが「完全」である必要があるという格言に従わず、代わりに、解決策が見つかって修正できる既知の問題を整理するためにバグ修正を含むパッチに依存しています。[要出典]

マーケティングとしてのバージョン番号

比較的一般的な方法は、マーケティング上の理由からバージョン番号を大幅に増やすことです。多くのお客様は、1.0ソフトウェアは未成熟であり、実稼働環境で信頼できないと考えているため、ソフトウェアベンダーは、1.0リリースをバイパスしたり、後続のバージョン番号のリリースをすぐにリリースしたりすることがあります。[要出典]たとえば、dBase IIの場合と同様に、製品は、それが実際よりも成熟していることを意味するバージョン番号で発売されます。

また、競合他社のバージョン番号と一致するようにバージョン番号が増加する場合もあります。これは、Microsoft、 America Online、Sun SolarisJava仮想マシン、SCO Unix、WordPerfectによる製品バージョン番号付けの多くの例で見ることができますMicrosoft Accessは、 Microsoft Wordのバージョン番号と一致するように、バージョン2.0からバージョン7.0にジャンプしました

Microsoftは「キャッチアップ」バージョン管理のターゲットでもあり、NetscapeブラウザはMicrosoftのInternet Explorerに沿ってバージョン5から6をスキップしますが、Mozillaアプリケーションスイートは1.0より前のユーザーエージェント文字列でバージョン5を継承したためです。開発とNetscape6.xは、Mozillaのコードベースに基づいて構築されました。

競合他社に追いつくもう1つの例は、1999年にSlackwareLinuxがバージョン4からバージョン7にジャンプしたときです。 [46]

迷信

  • MicrosoftOfficeのOffice2007リリースの内部バージョン番号は12でした。次のバージョンであるOffice2010の内部バージョンは、番号13を取り巻く迷信のため、14です。[47] Visual Studio 2013は製品のバージョン番号12.0であり、新しいバージョンであるVisual Studio2015のバージョン番号は同じ理由で14.0です。
  • Roxio Toastはバージョン12からバージョン14に移行しました。これは、おそらく13番を取り巻く迷信をスキップするためです。
  • CorelWordPerfectOfficeバージョン13は、「X3」(ローマ数字10および「3」)として販売されています。この手順は、次のバージョンであるX4まで継続されています。CorelのGraphicSuite(つまり、 CorelDRAWCorel Photo-Paint)とそのビデオ編集ソフトウェア「VideoStudio」でも同じことが起こりました。
  • Sybaseは、Adaptive Server Enterpriseリレーショナルデータベース製品のメジャーバージョン13および14をスキップし、12.5から15.0に移行しました。
  • ABBYY Lingvo Dictionaryは、番号12、x3(14)、x5(15)を使用します。
  • SUSE Linux Enterpriseは、バージョン12の後にバージョン13と14をスキップし、2018年7月にSLES15を直接リリースしました。

オタク文化

認識されているマーケティングの困難を克服する

1990年代半ば、急速に成長しているCMMSであるMaximoは、Maximoシリーズ3からシリーズ5に直接移行しました。これは、中国市場でのマーケティングの難しさから、シリーズ4をスキップしました。四の字)。ただし、これによってMaximo Series5バージョン4.0のリリースが停止することはありませんでした。(その後、「シリーズ」バージョン管理は廃止され、シリーズ5バージョン1.0のリリース後にバージョン番号が事実上リセットされました。)

重要性

ソフトウェア工学において

バージョン番号は、ソフトウェア製品のコピーを識別したり、開発者がリリースした最新バージョンなどの別のコピーと比較したりするために、消費者またはクライアントによって実際的な用語で使用されます。プログラマーや企業の場合、バージョン管理はリビジョンごとに使用されることが多く、ソフトウェアの個々の部分が、多くの場合、共同バージョン管理システムで、同じ部分の新しいリビジョンまたは古いリビジョンと比較および対比されます。

21世紀になると、セマンティックバージョニングポリシーなどの正式なバージョンポリシーを使用するプログラマーが増えました。[1]このようなポリシーの目的は、他のプログラマーが、コードの変更によって自分が書いたものが壊れそうな時期を簡単に知ることができるようにすることです。このようなポリシーは、ソフトウェアライブラリフレームワークにとって特に重要ですが、コマンドラインアプリケーション(他のアプリケーションから呼び出される場合もあります)や他のアプリケーション(サードパーティによってスクリプト化および/または拡張される場合があります)についても従うのに非常に役立ちます。 )。

バージョン管理は、ソフトウェアのパッチ適用とアップグレードの多くのスキームを有効にするため、特に何にどこにアップグレードするかを自動的に決定するためにも必要なプラクティスです。

テクニカルサポートで

バージョン番号を使用すると、サポートを提供するユーザーは、ユーザーが実行しているコードを正確に確認できるため、問題の原因などとしてすでに修正されているバグを除外できます。これは、プログラムに実質的なユーザーコミュニティがある場合、特にそのコミュニティが十分に大きく、テクニカルサポートを提供する人がコードを書いた人ではない場合に特に重要です。意味的意味[1]version.revision.changeスタイルの番号付けは、情報技術スタッフにとっても重要です。情報技術スタッフは、施設に展開する前に、新しいリリースにどれだけの注意と調査を払う必要があるかを判断するためによく使用します。経験則として、変更が大きいほど、何かが壊れる可能性が高くなります(ただし、変更ログを調べると、表面的または無関係な変更のみが明らかになる場合があります)。これが、Asterisk et aliaが採用した「メジャーリリースを削除する」アプローチで表現された嫌悪感の理由の1つです。現在、スタッフは更新ごとに完全な回帰テストを実行する必要があります(または少なくとも実行する必要があります)。

ソフトウェアの外部で使用する

OpenVMSファイルシステムなどの一部のコンピュータファイルシステムも、ファイルのバージョンを保持しています。ドキュメント間のバージョン管理は、コンピューターやソフトウェアエンジニアリングで使用されるルーチンと比較的似ており、構造、内容、または条件を少し変更するたびに、バージョン番号が1ずつ増加するか、個人に応じて値が小さくなります。著者の好みと行われた変更のサイズまたは重要性。

ソフトウェアスタイルのバージョン番号は、他のメディアで見つけることができます。

場合によっては、使用法は直接のアナロジーです(たとえば、 Jackass 2.5、追加の特別な機能を備えたJackass Number Twoのバージョン、バージョン2.0というタイトルのGarbageによるセカンドアルバム、またはルールが改訂されたDungeons&Dragons 3.5第3版ですが、第4版と見なされるほどではありません)。

多くの場合、ハイテクノロジーとの関連でプレイするために使用され、文字通り「バージョン」を示すものではありません(たとえば、Tron 2.0 、映画Tronのビデオゲームのフォローアップ、またはテレビシリーズThe IT Crowdは、バージョン2.0としての第2シーズン)。特に注目すべき使用法はWeb2.0で、ユーザー生成コンテンツ使いやすさ相互運用性を強調した2000年代初頭のWebサイトを指します。

も参照してください

メモ

  1. ^ クラシックMacOSバージョン(パッチを含まない)の完全なシーケンスは次のとおりです:1.0、1.1、2.0、2.1、3.0、3.2(3.1をスキップ)、4.0、4.1、5.0、5.1、6.0、7.0、7.1、7.5、7.6、 8.0、8.1、8.5(ジャンプ)、8.6、9.0、9.1、9.2。

参考文献

  1. ^ a b c d e f Preston-Werner、Tom(2013)。 セマンティックバージョニング2.0.0。クリエイティブコモンズ。https://semver.org/spec/v2.0.0.htmlから取得
  2. ^ ラム、パトリック; ディートリッヒ、イェンス; Pearce、David J.(2020年8月16日)。「セマンティクスをセマンティックバージョニングに入れる」。arXiv2008.07069 [ cs.SE ]。
  3. ^ 「SolarisおよびLinuxでのライブラリインターフェイスのバージョン管理」
  4. ^ 「Libtoolのバージョン管理システム」Libtoolのドキュメント
  5. ^ 「バージョン管理の番号付けの概念– ApachePortableRuntimeProject」2009年4月11日取得
  6. ^ 「Daemonite:バージョン番号付けの科学」2004年9月14日2009年4月11日取得
  7. ^ フランク・カイン、バート・ド・ビール、ルイス・マルティネス、ハリエット・モリル、ミハ・ペトリック、デビッド・ビガーズ、スージー・ウェンドラー。 「SystemzParallelSysplexのベストプラクティス」2011.p。6.6。
  8. ^ 「Windows用のOpera変更ログ」Operaソフトウェア2014 2014年11月6日取得
  9. ^ 「家」活字ドキュメントWiki2013年6月25日2014年11月6日取得
  10. ^ 「GNUコーディング標準:リリース」GNUプロジェクト2014年5月13日2014年5月25日取得各リリースは、バージョン番号のペア、メジャーバージョンとマイナーバージョンで識別する必要があります。2つ以上の数字を使用することに異論はありませんが、実際にそれらが必要になる可能性はほとんどありません。
  11. ^ a b "Advogato:バージョン番号の狂気"2000年2月28日2009年4月11日取得
  12. ^ Debianポリシーマニュアル、 5.6.12バージョン
  13. ^ 「Java版のバージョン履歴」公式MinecraftWiki 2019年3月6日取得
  14. ^ 「カレンダーのバージョン管理—CalVer」calver.org 2019年10月10日取得
  15. ^ マーカス・クーン(2004年12月19日)。「国際標準の日付と時刻の表記」ケンブリッジ大学2009年4月11日取得
  16. ^ ジェフアトウッド(2007年2月15日)。「コーディングホラー:とにかく、バージョン番号には何が含まれていますか?」2016年11月15日取得
  17. ^ 「PEP440–バージョンの識別と依存関係の仕様」
  18. ^ ドナルドE.クヌース。TeXとMETAFONTの未来、NTGジャーナルMAPS(1990)、489。デジタルタイポグラフィの第30章として転載、p。571。
  19. ^ 「Appleはteluguクラッシュ修正でmacOS10.13.3補足アップデートをリリースします」2018年3月26日取得
  20. ^ ギャラガー、ウィリアム(2020年6月22日)。「AppleはmacOSを最大11または10.16に変えます」AppleInsider。
  21. ^ ヒーター、ブライアン。「AppleがmacOS11.0 BigSurを発表」TechCrunch2020年6月22日にオリジナルからアーカイブされました2020年6月22日取得
  22. ^ De Looper、クリスチャン(2021年10月12日)。「ApplemacOSモントレー:これまでに知っていることはすべて」BGR。2021年10月12日にオリジナルからアーカイブされました。
  23. ^ 「Windows10の発表」
  24. ^ 「Windows11:PCの新時代が今日始まります」Windowsブログ2021年10月4日。
  25. ^ 「DebianFAQ:6.2.2これらのコードネームはどこから来たのですか?」2021年1月2日にオリジナルからアーカイブされました2021年1月2日取得
  26. ^ 「BLAGLinuxおよびGNU」DistroWatch.com 2011年9月29日取得
  27. ^ 「ニュースおよび更新:BLAG」DistroWatch.com 2011年9月29日取得
  28. ^ 「ブラッグダウンロード」ブラグ2011年9月29日取得
  29. ^ 「Kelvinバージョニング・jtobin.io」jtobin.io 2021年3月17日取得
  30. ^ urbit.org。「凍結されたオペレーティングシステムに向けて–Urbit」urbit.org 2021年3月17日取得
  31. ^ a b "ToaruOS1.0オープンソースOSは6年以上の開発後にリリースされました"2017年2月13日2017年5月23日取得
  32. ^ a b ギルバートソン、スコット。「ワインは1.0リリースに向かった。ついに」有線2017年5月23日取得
  33. ^ 「Firefoxリリースカレンダー–MozillaWiki」wiki.mozilla.org
  34. ^ 「同時リリース–Eclipsepedia」wiki.eclipse.org
  35. ^ 「ReleasePlan– The Document FoundationWiki」wiki.documentfoundation.org
  36. ^ 「リリース– UbuntuWiki」wiki.ubuntu.com
  37. ^ 「リリース– Fedora ProjectWiki」fedoraproject.org
  38. ^ 「PEP0– Python拡張提案(PEP)のインデックス」Python.org
  39. ^ 「リリースプラン」digikam.org2018年3月25日。
  40. ^ 「VMware製品リリーストラッカー(vTracker)」Virten.net2015年2月13日。
  41. ^ 「Node.jsはSemVerです」NodeSourceブログ– Node.jsチュートリアル、ガイド、および更新2015年9月15日。Linuxカーネルスタイルの奇数/偶数バージョン管理スキームを備えたノードを導入しました2018年3月26日取得
  42. ^ ケビンP.フレミング(2011年7月21日)。「アスタリスクの進化(または:アスタリスク10に到達した方法)|アスタリスクの内部」Digium、Inc 2014年5月25日取得
  43. ^ Torvalds、Linus: Linuxリリース0.01 kernel.org、1991に関する注記。
  44. ^ Calore、Michael(2009年8月25日)。「1991年8月25日:ヘルシンキからの子供はLinux革命を扇動する」有線2018年2月8日取得
  45. ^ それでも、マイケル; スミス、スチュワート(2007年12月15日)。実用的なMythTV:PVRおよびMedia CenterPCの構築ニューヨーク:Springer-Verlag New York、Inc.p。9. ISBN 978-1-59059-779-82018年4月15日取得
  46. ^ 「SlackwareFAQ」
  47. ^ Paul Thurrott(2009年5月14日)。「Office2010FAQ」2009年4月19日にオリジナルからアーカイブされました2009年12月30日取得
  48. ^ フィニー、ライアン(2010年10月23日)。「ごめんなさい」2012年2月9日取得

外部リンク