世界は役に立たない - ソフトウェアのバージョン番号の定義

ソフトウェアバージョン番号に関する注意事項

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

最近のコンピュータ ソフトウェアは通常、2 つの異なるソフトウェア バージョン管理スケジュールを使用して追跡されます。1 つはリビジョン管理番号のように 1 日に何度も増加するビルド番号、もう 1 つは意味的に準拠したバージョン番号やプロジェクト コードなど、通常はあまり頻繁に変更されないリリース バージョンです。名前。

文書番号は、文書や事件を一意に識別するために企業だけでなく特に行政機関でも使用されます。コンピュータ ファイルの場合、この手法は MIT の ITS ファイル システムで初めて導入され、その後 1972 年に PDP-10 用に TENEX ファイル システムが開発されました。

ファイルのリストは、バージョンとファイル間の依存関係を含めて、後で追加されました。Debian などの Linux ディストリビューション (dpkg など) は、パッケージ間の依存関係を解決するパッケージ管理ソフトウェアを長い間作成してきました。Debian の最初の試みでは、パッケージは、そのパッケージに依存する他のパッケージについて認識します。1994 年からは考え方が逆転し、パッケージは必要なパッケージを認識するようになりました。パッケージがインストールされると、依存関係の解決を通じて必要なパッケージが自動的に特定され、必要なパッケージとともにインストールされます。ソフトウェアのアップグレードを容易にするために、パッケージのバージョン変更を最小限に抑えることが望ましいです。したがって、番号付けスキームは、どれが最新の準拠バージョンであるかを識別できる必要があります。

シーケンスベースのソフトウェアバージョン管理スキームでは、各ソフトウェアバージョンに、1 つ以上の数字または文字のシーケンスで構成される一意の識別子が割り当てられます。ただし、スキームが異なれば、シーケンスの数、単一シーケンスの意味、シーケンスの増加方法などの点で大きく異なります。

一部のスキームでは、バージョン間の変更の重要性を表現するためにシーケンスベースの識別子が使用されます。変更は重要度によって並べ替えられ、バージョン間でどの変更が変更されるかを決定する順序は、前のバージョンと比較した変更の重要性であるため、最初の順序が最も重要な変更として変更され、最初の順序 A の後の変更が変更されます。変化は重要性の低下を表します。

シナリオに応じて、重要性は、変更されたコード行、追加または削除された機能ポイント、顧客への潜在的な影響 (新しいバージョンを採用するために必要な作業)、バグまたは予告なしの破損という観点から測定できます。 性的変化のリスク、性的変化の程度視覚的なレイアウト、新機能の数、または新しいバージョンが「以前のバージョンよりも優れている」ことを強調したいというマーケティング上の欲求を含む、製品開発者やマーケティング担当者が重要と考えるほとんどすべてのもの。

具体的な定義

一般的なバージョン番号の定義はメジャー番号とマイナー番号であり、その後にビルド番号、リビジョン番号 (ソース管理システムの番号)、リリース番号、タイムスタンプ、パッチ番号、セキュリティ問題の修正などの対応する情報エンコードが続きます。番号またはカスタム番号 (ビルド、リビジョン、リリース、日付スタンプ、ホットフィックス、セキュリティ修正、カスタム アルゴリズム)。たとえば、.Net 4.0 のバージョン定義は Major.Minor.Build.Revision ですが、Delphi では Major.Minor.Release.Build です。

C# AssemblyInfo.cs ファイル内の関連する定義は次のとおりです。

// アセンブリのバージョン情報は、次の 4 つの値で構成されます。

//

// メジャーバージョン

// マイナーバージョン

// ビルド番号

// リビジョン

//

/ すべての値を指定することも、ビルド番号とリビジョン番号をデフォルトにすることもできます

// 以下に示すように '*' を使用します。

// [アセンブリ: AssemblyVersion("1.0.*")]

バージョン番号の最も一般的に使用される形式は次のとおりです。

xyz（メジャー.マイナー.ビルド）

x はメイン バージョン番号で、主要な機能、インターフェイス、またはインターフェイスの変更、アプリケーション スタックのアーキテクチャの変更、プラットフォーム インフラストラクチャの変更、または公開されたネットワーク インターフェイスの変更を表します。互換性に影響を与える可能性があります。

y は、マイナー バージョン番号、マイナーな機能変更、マイナーな改善 (ローカル アーキテクチャの変更など)、バグ修正または内部アップデート、一般的な UI 調整、コンポーネントの追加またはアップデート、および API の変更を表します。同じ製品の異なるコンポーネントは使用できない場合があります。マイナーバージョン番号が異なる場合でも連携して動作します。

z はビルド番号 (ビルド番号) で、通常はソフトウェアの「バージョン情報」ウィンドウに表示され、カスタマー サポートで詳細情報を提供するために使用されます。これは自由な形式であり、各製品を個別に定義できます。毎日 1 つ、リリースごとに 1 つ、またはビルドごとに 1 つです。ビルド番号はプレリリース番号としても使用できます。この番号は変化し続けます。一定のレベルに達すると、新しいマイナー バージョン リリースがトリガーされます。

ソフトウェアのバージョン番号が変更された場合は、同じバージョンを維持するか、ソフトウェアに含まれるコンポーネントのバージョン番号を増やします。すべてのコンポーネントのバージョン番号を共有することも、変更されたコンポーネントのバージョン番号のみを増やすこともできます。

データベースを備えたソフトウェアの場合:

1. 最初の数字はシステム全体のバージョンを示し、通常は数年に一度だけ変更され、通常はテクノロジーの根本的な変更、顧客が使用する機能、あるいはその両方を表します。

2 の 2 番目の数字は、データベース モデルのリビジョンを示します。この数を増やすにはデータベースの移行が必要になるため、システムのバックアップが必要になる可能性のある大きな変更となるため、データベース構造の変更には慎重なアップグレード プロセスが必要になります。最初の数値が変更されると 0 にリセットされます。

3. 3 番目の数字は純粋にソフトウェアの変更を示します。データベース構造は変更されていないため、これは通常、クライアントによってクライアント側で実行できます。2 番目の数値が変化すると 0 にリセットされます。

4. Subversion のバージョン番号。たとえば、TortoiseSVN ツールを使用して、ビルド時にこの数値を自動的に入力します。この数値はリセットされることはなく、増加し続けます。この番号を使用すると、いつでも任意のバージョンを再作成できます。

データベースのリビジョンを追跡する必要がない場合は、3 桁または 2 桁のバージョン番号を使用するだけで簡単です。(これはビルド番号のようなもので、この番号の情報形式は状況に応じて決定できます)

1. 最初の数字 = システム全体の時代。変更は数年ごとに行われ、通常はテクノロジー、クライアント機能、またはその両方の根本的な変更を表します。

2. 2 番目の数字 = データベース スキーマのリビジョン。この数値を増やすにはデータベースの移行が必要なため、大幅な変更になります (またはシステムが複製されるため、データベース構造を変更するには慎重なアップグレード プロセスが必要です)。最初の数値が変更されると 0 にリセットされます。

3. 3 番目の番号 = ソフトウェアのみの変更。データベース スキーマは変更されないため、これは通常、クライアントごとに実装できます。2 番目の数値が変化すると 0 にリセットされます。

4. Subversion のバージョン番号。これは、TortoiseSVN ツールを使用してビルド時に自動的に設定されます。この数値はリセットされることはなく、継続的に増加します。これを使用すると、いつでも任意のバージョンを再作成できます。

すべての数字には明確で重要な機能があるため、このシステムは私たちに役立っています。他のチームがメジャー番号とマイナー番号の問題 (どのくらい大きな変更がメジャーなのか) に取り組んでいるのを見てきましたが、それがメリットだとは思えません。データベースのリビジョンを追跡する必要がない場合は、3 桁または 2 桁のバージョン番号を参照するだけで作業が簡単になります。

セマンティック バージョニング

セマンティック バージョニングの仕様は、セマンティック バージョニング [semver2.0] (セマンティック バージョニング 2.0.0 | セマンティック バージョニング)にあります 。

セマンティック バージョニング (SemVer とも呼ばれる) は、3 つの部分からなるバージョン番号 (Major.Minor.Patch)、オプションのプレリリース タグ、およびオプションのビルド メタ タグ (オプションのビルド メタ タグ) を使用して、広く採用されているバージョン管理スキームです。バージョンをエンコードします。このアプローチでは、リスクと機能がソフトウェア変更の影響を測定する基準になります。重大な変更はメジャー バージョン番号を増加することで示され (高リスク)、新しい非破壊機能はマイナー バージョン番号を増加し (中リスク)、他のすべての非重大な変更はパッチ番号を増加します (最低リスク)。プレリリース タグ (-alpha、-beta) の存在は重大なリスクを示し、メジャー バージョン番号 0 (0.yz) も同様です。これは、あらゆる程度の潜在的な破壊的変更が含まれる可能性がある進行中の作業を示すために使用されます。 （最も高いリスク）。SemVer バージョンから互換性を推測する例として、バージョン 2.1.5 API に依存するソフトウェアはバージョン 2.2.3 と互換性がありますが、必ずしもバージョン 3.2.4 とは互換性があるとは限りません。

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

別のアプローチは、メジャー番号とマイナー番号、および「アルファ」(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。この計画では、リリース候補段階で新機能や重大な変更をロックするのが一般的であり、一部のチームでは、最終バージョンとの整合性を確保するためにバグ修正のみを許可するためにベータ版さえロックされています。

他のスキームでは、個々のシーケンスに意味を割り当てます。

メジャー.マイナー[.ビルド[.リビジョン]] (例: 1.2.12.102)

major.minor[.maintain[.build]] （例如：1.4.3.5249）。

また、これらの例では、何を「ビルド」として定義するか、または「改訂」と「マイナー」の区別と同様に、「メジャー」変更と「マイナー」変更を構成するものの定義は完全に主観的であり、作成者に任されています。変化します。

Solaris および Linux の共有ライブラリでは、current.revision.age 形式を使用できます。ここで、

current: ライブラリによって実装された最新のインターフェイス番号。

リビジョン: 現在のインターフェースの実装番号。

age: ライブラリによって実装された最新のインターフェイスと最も古いインターフェイスの差。3 番目のフィールドのこの使用法は libtool に固有です。他のフィールドでは別の意味が使用されるか、単に無視される場合があります。

意味やバージョン名の相対的な変化に関する同様の問題は書籍の出版にも存在し、さまざまな基準に従ってバージョン番号や名前が選択されることがあります。

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

互換性（互換性の程度）

一部のプロジェクトでは、互換性のないバージョンを示すためにメジャー バージョン番号を使用します。2 つの例としては、Apache Portable Runtime (APR) と FarCry CMS があります。

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

多くの場合、パケット ヘッダーとファイル形式にはバージョン番号が含まれており、ソフトウェアが書き込まれたときと同じバージョン番号である場合もあれば、ソフトウェアのバージョン番号とは別の「プロトコル バージョン番号」である場合もあります。古い非推奨のプロトコルやファイル形式を扱うコードは、多くの場合、迷惑なものとみなされます。

開発段階のバージョン番号を指定する（開発段階の指定）

実験段階 (アルファまたはベータ) にあるソフトウェアは通常、シーケンスの最初 (「メイン」) 位置に 0 を使用してその状態を指定します。ただし、この解決策は初期段階でのみ有用であり、リリース間近でバージョン番号が 0 を超えた成熟したソフトウェアには適していません。

新しいバージョンの状態を表すために使用されるスキームがいくつかあります。

英数字のサフィックスは、セマンティック バージョニングで採用される一般的なスキームです。このスキームでは、ステータスを示すために各バージョンにダッシュといくつかの英数字が追加されます。

デジタル状態は、数値を使用して状態をシーケンスの一部であるかのように表すスキームです。一般的な選択は、4 桁バージョンの 3 桁目です。

Digital 90+ は数値を使用するもう 1 つのスキームですが、明らかに以前のバージョンの数値よりも下回っています。最後の位置には大きな数値を使用します (通常は 90 以上)。これは、Fontconfig などの古いオープンソース プロジェクトでよく使用されます。

たとえば、バージョン 1.2 がリリースされる場合、プレリリース バージョンは 1.1.90 以上になります。

開発段階指標の比較
発達	セマンティック	数値	数値
ステージ	バージョン管理	スターテス	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
リリース候補 (RC)	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など。

一方、一部のパッケージでは、1.7、1.8、1.81、1.82、1.9 などの 10 進数でバージョンを識別します。1980 年代には NetWare、DOS、Microsoft Windows などで 10 進数バージョンが一般的でしたが、2000 年代でも Opera や Movable Type が使用されていました。10 進数スキームでは、1.81 は 1.8 の後のマイナー リリースですが、メンテナンス リリース (つまり、バグ修正のみ) は、1.81a や 1.81b などの 1 文字の接尾辞で表すことができます。

標準の GNU バージョン番号付けスキームは、major.minor.revision ですが、Emacs は、メジャー番号が削除され、ユーザー サイトのリビジョンが追加される代替スキームを使用する注目すべき例です。元の Emacs パッケージでは常に 0 ですが、増分されます。ディストリビューターによる。また、Debian パッケージ番号には、バージョン管理スキームの変更を許可するために使用されるオプションの「エポック」が接頭辞として付けられます。

リセット

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

シーケンスの分離

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

スキームでは、すべてのシーケンス間で同じ文字を使用できます: 2.4.13、2/4/13、2-4-13

プロトコルは、どのシーケンスを分離するかの選択において一貫性がなく、一部のシーケンスは分離するが、他のシーケンスは分離しない可能性があります: 2.413

スキームでは、同じ識別子 2.4_13 内の文字の選択が一貫していない可能性があります (例: Minecraft Beta は 1.7 から 1.7_01、1.7.2 に増加しました)

シーケンスを区切るためにピリオドが使用される場合、ピリオドは小数点を表す場合とそうでない場合があり、それが 10 進数の場合、それは小数点ではありません。

シーケンスの数

場合によっては、ソフトウェアのビルド (Microsoft が使用する) を示す 4 番目の未公開の番号も存在​​します。Adobe Flash はその顕著な例で、10.1.53.64 など 4 つのバージョン番号が公開されています。一部の企業では、ビルド日も記載されています。バージョン番号には、Lotus 1-2-3 Release 1a などの文字やその他の文字を含めることもできます。

負の数

一部のプロジェクトでは負のバージョン番号を使用します。例としては、-1.0 から始まり 0.0 までカウントされる SmartEiffel コンパイラがあります。

リリース日

CalVer 形式でリリース番号を表示するストリートファイター EX のスプラッシュ画面:「961219 USA」

多くのプロジェクトでは、Calendar Versioning (CalVer とも呼ばれる) と呼ばれる日付ベースのバージョン管理スキームが使用されています。

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

ファイル名などのバージョン管理で日付を使用する場合、文字列を昇順または降順に並べ替えることが容易になるため、通常は ISO 8601 スキーム YYYY-MM-DD が使用されます。ハイフンは省略される場合があります。Wine プロジェクトでは、年、月、リリース日の順に使用する日付付きバージョン管理スキームが使用されていました (たとえば、「Wine 20040505」)。Minecraft にも同様のバージョン形式がありますが、代わりに DDHHMM を使用します。例: rd-132211、13 は 2211 年 5 月 13 日の 22:11 です。

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

年マーク付きバージョンの他の例としては、Adobe Illustrator 88 や WordPerfect Office 2003 などがあります。バージョンを示すために年が使用される場合、通常はマーケティング目的で使用され、実際のバージョン番号も存在​​します。たとえば、Windows 95 のビルドは MS-DOS 7.00 と Windows 4.00 であり、同様に Windows 2000 のビルドは NT 5.0 です。

その他のプログラム

一部のソフトウェア製作者は、ソフトウェア リリースを表すために異なるスキームを使用しています。Debian プロジェクトは、オペレーティング システムのリリースにメジャー/マイナー リリース スキームを使用していますが、開発中の安定リリース、不安定リリース、およびテスト リリースを指すために映画トイ ストーリーのコード名を使用しています。

BLAG Linux および GNU は、非常に大きなバージョン番号が特徴です。メジャー バージョンには 50000 や 60000 などの番号があり、マイナー バージョン番号は 1 ずつ増加します (50001、50002 など)。α版、β版のバージョン番号は、本体バージョン番号より1つ小さい番号で、例えば19999.00071はバージョン20000のα1、29999.50000はバージョン30000のβ2を意味します。2003 年の 9001 から始まり、2011 年現在の最新バージョンは 140000 です。

Urbit は、ケルビン バージョン管理方法 (絶対ケルビン温度スケールにちなんで名付けられました) を使用します。つまり、ソフトウェア バージョンは高い番号から始まり、バージョン 0 までカウントダウンされ、その時点でソフトウェアは完成したとみなされ、それ以上の変更は行われません。

内部バージョン番号

ソフトウェアには、製品名に示されているバージョン番号とは異なる「ビルド」バージョン番号が付いている場合があります (通常は、より一貫してバージョン番号規則に従います)。たとえば、Java SE 5.0 のビルド番号は 1.5.0 ですが、NT 4 以降の Windows バージョンは引き続き標準の番号が付けられたバージョンを内部的に使用します。Windows 2000 は NT 5.0、XP は Windows NT 5.1、Windows Server 2003、および Windows XP です。 Professional x64 Edition は NT 5.2、Windows Server 2008 および Vista は NT 6.0、Windows Server 2008 R2 および Windows 7 は NT 6.1、Windows Server 2012 および Windows 8 は NT 6.2、Windows Server 2012 R2 および Windows 8.1 は NT 6.3、ただし、Windows 10 の最初のリリースは 10.0 (10.0.10240) でした。ただし、Windows NT は現在 5 番目のメジャー リビジョンにすぎないことに注意してください。最初のバージョンの番号は (当時の Windows のバージョン番号に合わせて) 3.1 であり、Windows 10 では 6.3 から 10.0 にジャンプしました。

プレリリース版

上記のさまざまなリリース スケジュールと組み合わせて、ソフトウェア リリース サイクルのさまざまなフェーズを管理するプレリリース バージョンを表すシステムを使用するのが一般的です。

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

一部のシステムでは、最終バージョン「1.0」に近いことを示すために、1 未満の数値バージョン (0.9 など) を使用します。これはオープンソース ソフトウェアでは一般的な方法です。ただし、プレリリースが既存のパッケージ (バージョン 2.5 など) の場合は、バージョン番号に「a」または「alpha」を追加できます。したがって、バージョン 2.5 のアルファ リリースは 2.5a または 2.5.a として識別できます。

もう 1 つのアプローチは、プレリリース バージョンを「リリース候補」と呼ぶことです。これにより、特定のリリースとしてリリースされようとしているパッケージには、そのリリース タグの後に候補バージョンの番号を示す「rc-#」を付けることができます。最終バージョンがリリースされると、「rc」タグは削除されます。

リリーストレイン

ソフトウェア リリース トレインは、複数の製品の異なるバージョン ソフトウェア シリーズがいくつかの異なる「トレイン」として定期的にリリースされるソフトウェア リリース スケジュールの形式です。一般に、製品ファミリーごとに、初期リリースから最終的に成熟し、計画された時間枠内で終了するまで、特定の時点で多数の異なるリリース トレインが実行されます。ユーザーは、実稼働環境に採用する前に、より新しいリリース トレインを試すことができます。これにより、実稼働システムで以前のトレインのリリースを追跡し続けながら、新しい「未加工」リリースを早い段階で試すことができ、その後、新しいリリース トレインで実行できます。成熟するにつれて訓練します。

Cisco の IOS ソフトウェア プラットフォームは、長年にわたってさまざまなリリース スケジュールを使用してきました。最近では、Android 用 Firefox や Fenix、Eclipse、LibreOffice、Ubuntu、Fedora、Python、digiKam、VMware など、他の多くのプラットフォームでリリース トレイン モデルが採用されています。

一部のメーカーはメインのバージョン番号を放棄しました (最も重要な要素を削除しました)

Sun の Java にもハイブリッド システムがある場合があり、ビルド番号は常に 1.x ですが、市場では x のみが言及されています。

JDK 1.0.3

JDK 1.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 の最初の数字も削除し、マーケティング資料では Solaris 2.8 (または 2.9) を Solaris 8 (または 9) と呼んでいます。

Asterisk オープンソース PBX ビルド スイートも 2010 年代初頭に同様の飛躍を遂げ、そのプロジェクト リーダーは現在の 1.8.x リリースに続いて間もなく 10.x リリースがリリースされると発表しました。

この慣行は、バージョン番号の各部分の意味論的な意味を壊すものであるため、多くの人から批判されましたが、Mozilla (Firefox 用) を含む、ますます多くのベンダーで採用されるようになりました。

奇数番号と偶数番号のバージョン

1.0 と 2.6.x シリーズの間では、Linux カーネルは開発リリースには奇数のマイナー バージョン番号を使用し、安定リリースには偶数のマイナー バージョン番号を使用しました。「Linux カーネル § バージョン番号付け」を参照してください。たとえば、Linux 2.3 は Linux カーネルの 2 番目のメジャー設計の開発シリーズであり、Linux 2.4 は Linux 2.3 が成熟した後の安定したリリース シリーズです。Linux カーネルのマイナー バージョン番号の後には、リリース番号が昇順で表示されます (例: Linux 2.4.0 → Linux 2.4.22)。2004 年の 2.6 カーネルのリリース以来、Linux はこのシステムを使用しなくなり、より短いリリース サイクルを採用しています。

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

バージョン番号の順序付けの問題 (バージョン番号順序付けシステム)

バージョン番号は、単純な整数 (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 と見なされます。これによりユーザーが混乱する可能性があり、文字列照合ツールが特定のバージョン番号を見つけられない可能性があり、プログラマーがバージョン番号でインデックス付けされたハッシュ テーブルなどの文字列でインデックス付けされたデータ構造を使用する場合、パッケージ管理で問題が発生する可能性があります。

分類を容易にするために、一部のパッケージでは、メジャー.マイナー.リリース スキームの各コンポーネントを固定幅で示しています。Perl はバージョン番号を浮動小数点数として表します。たとえば、Perl バージョン 5.8.7 は 5.008007 と表すこともできます。このように、理論上のバージョン 5.8.10 は 5.008010 と表現できます。他のパッケージでは、各セグメントが固定ビット幅にパックされます。たとえば、Microsoft Windows では、バージョン番号 6.3.9600.16384 は 16 進数で 0x0006000325804000 と表現できます。バージョン番号のいずれかのセグメントが 999 を超えると、浮動小数点スキームは失敗し、セグメントあたり 16 ビットを使用するバイナリ パッキング スキームは、65535 を超えると失敗します。

Python でのバージョン番号の使用例

Python Software Foundation は、PEP 440 - バージョン識別と依存関係の仕様を公開し、エポック セグメント、リリース セグメント、プレリリースおよびポストリリース、開発リリース セグメントを定義する独自の柔軟なスキームの概要を説明しました。

バージョン番号 TeX の使用例

TeX には特別なバージョン番号付けシステムがあり、開発者の Donald Knuth によって発明された珍しい機能です。バージョン 3 以降、バージョン番号が数値 π に近づくように最後に余分な数字を追加することによって更新が示されます。これは単数形の番号付けの形式であり、バージョン番号は桁数です。現在のバージョンは 3.141592653 です。これは、TeX が非常に安定しており、マイナーなアップデートのみが期待されることを反映しています。TeX 開発者の Donald Knuth 氏は、絶対的な最後の変更はバージョン番号を π に変更することであり、その時点で残っているすべてのバグは永続的な機能になるだろうと述べています。

同様に、Metafont のバージョン番号はオイラー数 e (2.72...、自然対数の底) に漸近します。Metafont の現在のバージョン番号は 2.71828182 です。Metafont は、Donald Knuth によって、TeX 植字システムの付属品として設計されました。

バージョン番号の使用例 Apple Inc.

クラシックな Mac OS の時代には、マイナー バージョン番号に「.1」が付加されることはほとんどありませんでした。したがって、「8.5」は「Mac OS 8.5」を表す独自のバージョンとして販売されましたが、8.6 は実際には「8.5.1」を意味しました。

Mac OS X はこの傾向から逸脱しましたが、その主な理由は、製品名に「X」（ローマ数字の 10）が含まれていたためです。したがって、OS X のすべてのバージョンは数字 10 で始まります。OS X の最初のメジャー リリースにはバージョン番号 10.0 が付けられましたが、次のメジャー リリースは 11.0 ではありませんでした。代わりに、後続のメジャー リリースごとに、10.1、10.2、10.3 というように番号が付けられます。したがって、OS X の 11 番目のメジャー リリースには「10.10」というラベルが付けられます。macOS 10.12 以降、名前から「X」が削除されましたが、この番号付けスキームは macOS 10.15 まで継続されました。「X」ベースのリリース計画では、(2 番目ではなく) 3 番目の数字はマイナー バージョン、そのレベル以下の追加アップデート、および新しいメジャー バージョンがリリースされた後の OS X への特定のメジャー アップデートを示します。バージョン アップデートと呼ばれます。補足的なアップデート。

ローマ数字の X は、複数の製品ラインにわたるマーケティング目的で同時に使用されます。QuickTime と Final Cut Pro は両方とも、バージョン 7 からバージョン 10、つまり QuickTime X と Final Cut Pro X に直接移行しました。Mac OS X 自体と同様、これらの製品は以前のバージョンからのアップグレードではなく、まったく新しいプログラムです。OS X と同様、これらのプログラムのメジャー バージョンでは 2 桁目が追加され、マイナー バージョンでは 3 桁目が使用されます。macOS 11.0 のリリースにより、Final Cut の名前の「X」が削除され (下記を参照)、2011 年に QuickTime フレームワークが AVFoundation に代わって非推奨になったとき、QuickTime ブランドは無意味になりました (QuickTime ビデオ用のプログラムは知られています)当初から QuickTime Player としてのみ)。

Apple の次期 macOS バージョン（仮番号 10.16）は、2020 年 6 月の WWDC で macOS 11 として正式に発表され、2020 年 11 月にリリースされました。次の macOS リリースである macOS Monterey は 2021 年 10 月にリリースされ、メジャー バージョン番号が 12 に上がります。

バージョン番号の使用例 Microsoft Windows

Microsoft Windows オペレーティング システムは当初、Windows 1.0 から Windows 3.11 までを識別するために標準のバージョン番号を使用していました。その後、Microsoft は製品名からバージョン番号を除外しました。Windows 95 (バージョン 4.0)、Windows 98 (バージョン 4.10)、および Windows 2000 (バージョン 5.0) の場合は、製品名に発売年が含まれています。Windows 2000 の後、Microsoft は Windows Server シリーズを作成し、年ベースのスタイルを継続しましたが、1 つ違いがありました。マイナー リリースの場合、Microsoft はタイトルに「R2」を追加しました (例: Windows Server 2008 R2 (バージョン 6.1))。このスタイルは現在まで維持されています。ただし、Windows のクライアント バージョンは一貫したスタイルに従っていません。まず、Windows Me (4.90)、Windows XP (5.1)、Windows Vista (6.0) など、任意の英数字の接尾辞が付いた名前が与えられました。またしても、Microsoft はタイトルに増分番号を使用しましたが、今回はバージョン番号ではなく、Windows 7、Windows 8、および Windows 8.1 のバージョン番号はそれぞれ 6.1、6.2、および 6.3 でした。Windows 10 では、バージョン番号が 10.0 に跳ね上がりましたが、その後のオペレーティング システムの更新では、ビルド番号と更新ビルド リビジョン (UBR) 番号のみが増加しました。

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

ソフトウェア リリースのバージョン番号の重要性 (重要性):

ソフトウェア エンジニアリングの実際の応用では、バージョン番号は、消費者または顧客がソフトウェア製品のコピーを識別したり、開発者がリリースした最新バージョンなどの別のコピーと比較したりするために使用されます。プログラマーや企業の場合、バージョン番号は通常、ソフトウェアの継続的な変更 (通常はバージョン管理システムに含まれるソフトウェアの個々のコンポーネントを含む) に基づいて変更されます。

ソフトウェアのバージョン管理戦略は、ソフトウェア ライブラリとフレームワークにとって特に重要ですが、コマンド ライン アプリケーション (他のアプリケーションによって呼び出される可能性がある) や実際に他のアプリケーション (サードパーティによってスクリプト化または拡張できる) にも非常に役立ちます。

バージョン管理は、多くのソフトウェアのパッチ適用およびアップグレード スキームを実装するために、特にアップグレード方法を自動的に決定するために必要な実践でもあります。

サポートを提供する担当者はバージョン番号を使用して、ユーザーが実行しているコードを正確に判断できるため、問題の原因としてすでに修正されているバグを除外できます。これは、プログラムのユーザー ベースが大きい場合、特にユーザー ベースが大きすぎて、技術サポートを提供する人がコードを書いた人ではない場合に特に重要です。version.revision.change スタイル番号のセマンティクスは、IT 専門家にとっても重要であり、多くの場合、新しいバージョンを施設に展開する前に、どの程度の注意と調査を行う必要があるかを判断するためにこの番号を使用します。経験則 (経験則) として、バージョン番号の変更が多ければ多いほど、バグが存在する可能性が高くなります (ただし、変更ログを確認すると、表面的または無関係な表面的または無関係な変更のみが判明する可能性があります)。これが、Asterisk のような企業が採用する「メジャー バージョンを削除する」アプローチに対する一部の嫌悪感の理由の 1 つです。更新ごとに徹底的な回帰テストを行う必要がある (または少なくともそうする必要がある) からです。

たとえば、リリースされたソフトウェアが純粋なライブラリである場合、バージョン番号の比較を使用すると、互換性のレベル (互換性のレベル) とアップグレードの影響を示すことができます。

小さなバグ修正の場合は、バイナリ形式、ソース コード、およびシリアル化の互換性を維持する必要があります (バグ修正リリースでは、バイナリ、ソース コード、およびシリアル化の互換性を維持する必要があります)。

マイナー バージョン番号の変更はプロジェクトごとに異なる意味を持ちますが、通常はソース コードのマイルストーンを表し、ソース コードの非互換性と見なすことができます。

メジャー バージョンの変更では、より大きな変更が行われるため、バイナリ、ソース、シリアル化の互換性が失われる可能性があります。

一部の販売ソフトウェアには、販売後のサポート期間が限られている場合や、バージョン範囲が限定されている場合があります。たとえば、同じメジャー バージョン番号を持つソフトウェアのみがサポートされます。サポート範囲を拡大する必要がある場合は、新たな販売契約が必要となります。

ユーザーがソフトウェアを購入した後、ソフトウェアのアップグレードが必要な場合は、契約に従って、限られた期間内または限られたバージョンの範囲内で行われる場合もあります。すなわち、ソフトウェア購入後のアフターフォローサービスはバージョン変更に伴うものであり、バージョン番号の変更に応じてユーザーの権利利益に影響を与えるものである。

製品が市場に投入された後は、さまざまなマーケティング バージョン管理スキームが使用される場合があります。つまり、バージョン番号が大きいほど優れており、バージョン番号が大きいほど優れており、バージョン番号が小さいよりも優れており、バージョン番号が大きいほど優れています。競合他社のバージョン番号。

たとえば、Apple 携帯電話のバージョンは新しい世代、つまりバージョン番号が 1 つ増えており、識別するのに非常に便利です。バージョン番号が大きいほど新しいほど優れています。たとえば、iPhone 13 よりも iPhone 14 の方が優れています。

さらに、Apple は新世代の携帯電話を設計する際に、最新の携帯電話を使用していることが他の人にわかるように外観上の差別化も図っており、人々の購買意欲を刺激します。

その後、Xiaomi 13 携帯電話など、Xiaomi 携帯電話のバージョン定義でも同様のルールが使用されました。

デジタル情報の数に加えて、より人間に優しい表現を施したバージョンを区別するための特別な名前がいくつかあります。たとえば、Max OS のバージョン: Cheetah (チーター) から Ventura (カリフォルニアの都市の名前) まで。

見る：

Mac が使用している macOS を確認する - Apple サポート

https://en.wikipedia.org/wiki/MacOS

バージョン番号集計の非ソフトウェア分野への応用

一部のファイルシステムでは、ファイルにもバージョン番号が付けられます。ファイル内のバージョン番号は、コンピュータやソフトウェア工学で使用されるルーチンに似ています。構造、内容、または条件が変更されると、バージョン番号は 1 ずつ増加します。どのバージョン番号を追加するかは、作成者の個人的な好みやサイズによって異なります。変化の大きさ、重要性。

===区切り線===

政治的または文化的に重要な一部のバージョン番号

一般にメジャーバージョン0は開発バージョンを指し、ソフトウェアが不完全または安定して使用できないことを意味し、この時点のバージョンには下位互換性がない可能性があります。バージョン 1.0 は正式リリースのマイルストーンであり、開発者がこのバージョンで実装したいと考えている主要な機能が少なくともすべてソフトウェアに備わっており、十分な信頼性があると見なされ、通常どおりリリースされることを示します。良い例は Linux カーネルです。Linux カーネルは 1991 年にバージョン 0.01 として初めてリリースされ、1994 年までバージョン 1.0.0 に達しませんでした。

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

インターネットの普及以来、ほとんどの商用ソフトウェア ベンダーは、メジャー リリースは完了する必要があるという格言に従いません。代わりに、発生し、発見され、修正できる解決策がある問題に対処するために、バグ修正を含むパッチに依存するようになりました。 。

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

また、競合他社のバージョンに合わせてバージョン番号が大きくなる場合もあります。これは、Microsoft、America Online、Sun Solaris、Java Virtual Machine、SCO Unix、WordPerfect の製品バージョン番号の多くの例に見られます。Microsoft Access は、Microsoft Word のバージョン番号と一致するように、バージョン 2.0 からバージョン 7.0 に移行しました。

Microsoft のバージョン番号は、他の企業が追いつく目標でもあります。Netscape ブラウザはバージョン 5 からバージョン 6 にジャンプしましたが、これは Microsoft の IE ブラウザと一致していますが、これは Mozilla アプリケーション スイートが開発プロセス中にユーザー エージェント文字列を変更したためでもあります。 1.0 より前。バージョン 5 を継承し、Netscape 6.x は Mozilla のコードに基づいています。

競争に負けないもう 1 つの例は、1999 年の Slackware Linux のバージョン 4 からバージョン 7 へのジャンプです。

バージョン番号は迷信の影響を受けることもあります。Microsoft Office 2007 バージョンのビルド番号は 12 です。次のバージョンである Office 2010 のビルド 14 は、13 という数字にまつわる迷信のためです。同じ理由で、Visual Studio 2013 の製品バージョン番号は 12.0 で、新しいバージョンの Visual Studio 2015 のバージョン番号は 14.0 です。

Roxio Toast はバージョン 12 からバージョン 14 になり、おそらく 13 という数字にまつわる迷信は無視されます。

Corel の WordPerfect Office バージョン 13 は、「X3」(ローマ数字の 10 と「3」) として販売されています。このプロセスは次のバージョンである X4 まで続きました。同じことが、Corel のグラフィックス スイート (CorelDRAW、Corel Photo-Paint) とそのビデオ編集ソフトウェア「Video Studio」でも起こります。

Sybase は、Adaptive Server Enterprise リレーショナル データベース製品のメジャー 13 および 14 リリースをスキップし、12.5 から 15.0 に移行しました。

ABBYY Lingvo 辞書では、数値 12、x3 (14)、x5 (15) が使用されます。

SUSE Linux Enterprise は、バージョン 12 以降のバージョン 13 と 14 をスキップし、2018 年 7 月に SLES 15 を直接リリースしました。

オタク文化の影響を受けたバージョン番号の割り当てもあります。バージョン 4.2 以降の SUSE Linux ディストリビューションは、ダグラス アダムスの『銀河ヒッチハイク ガイド』で言及されている参照 42、「生命、宇宙、そしてすべてに関する究極の質問への答え」から始まります。

バージョン 13.37 の Slackware Linux ディストリビューション (leet によって参照)。

Finnix がバージョン 93.0 からバージョン 100 に移行したのは、Windows 95 に言及した「Finnix '95 は存在しない」という主張を実現するためでもありました。

===区切り線===

リリースには、メジャー、マイナー、緊急の 3 種類があります。

メジャーバージョンのリリース

通常、メジャー バージョンの変更は、ソフトウェアの以前のバージョンを無効にします。

メジャー リリースには、多数の製品変更と機能の重要な改善が含まれます。たとえば、メジャー リリースには次のものが含まれる場合があります。

• パフォーマンスとスケーラビリティを向上させるためにコードを書き直す

• ユーザー インターフェイスを変更して新しい外観と操作性を実現

• 使い方を変える新機能のリリース

• 廃止された機能または非推奨の機能を削除する

• 新しいソフトウェア統合を提供します

• 新しいハードウェアとの互換性

メジャー リリースはユーザーにとって最も大きな混乱をもたらします。新しいものが導入されるため、ダウンロードや設定に時間と労力がかかる場合があります。

これは、メジャー リリースが嫌われる可能性があり、顧客にトレーニングを提供したり、データを新しいバージョンに移行するのに時間を費やすことが必要になる場合があることを意味します。

また、互換性の問題や変更を示すこともあります。たとえば、新しいメジャー リリースには、古いハードウェアや古いプログラムとの下位互換性がない可能性があります。

したがって、ソフトウェアのメジャー バージョンをリリースするときは、必ずユーザーに情報を提供してください。彼らを驚かせないようにし、ソフトウェアの新しいバージョンをサポートする準備ができているかどうかを確認してください。

メジャーバージョンのリリース

通常、これらはソフトウェアの以前のリリースを無効にします。

メジャー リリースでは、製品に大幅な変更が加えられ、機能の重要な改善が展開されます。たとえば、メジャー リリースには次のものが含まれる場合があります。

* 書き直されたコードベースにより速度と復元力が向上

* ユーザー インターフェースが変更され、見た目も操作性も新しくなりました

* 革新的な新機能のリリース

* 古い機能または削除された機能の削除

* 新しいソフトウェアへの統合および/または新しいハードウェアの互換性

メジャーリリースがユーザーにとって何を意味するか

メジャー リリースはユーザーにとって最も大きな混乱をもたらします。新しいものが導入されるため、ダウンロードや設定に時間と労力がかかる可能性があります。

これは、メジャー リリースが変更を嫌う原因となる可能性があることを意味します。顧客にトレーニングを提供したり、データを新しいバージョンに移行するための専用の時間を必要としたりする場合があります。

また、互換性に関する問題や変更を意味する場合もあります。たとえば、メジャー リリースには、古いハードウェアやレガシー プログラムとの下位互換性がない場合があります。

したがって、メジャー ソフトウェア リリースの準備をしているときは、ユーザーに最新情報を常に伝えておくようにしてください。彼らを驚かせないようにし、ソフトウェアの新しいバージョンで彼らをサポートする準備ができていることを確認してください。

マイナーバージョンリリース

マイナー リリース (更新とも呼ばれます) は、メジャー リリースに基づいてインストールされます。つまり、ソフトウェアの現在のバージョンを変更します。

マイナー リリースは、メジャー リリースよりも小さな変更です。これらは、ソフトウェア製品への完全な見直しや新規追加ではありません。代わりに、既存の機能を強化および改善します。

したがって、マイナー リリースには次のものが含まれる場合があります。

• 限定された新機能と機能

• 既存の機能のマイナーアップデート

• 軽微なバグ修正と継続的なセキュリティ パッチ

多くのソフトウェアは実行中に定期的にマイナー バージョンのアップデートをチェックし、一部のソフトウェアはバックグラウンドでバージョン アップグレードを完了します。

マイナー バージョン リリースでは、ユーザーに何らかの混乱が生じる可能性があります。ただし、メジャー リリースほど影響力はありません。

マイナー バージョンのリリースは、ソフトウェア ユーザーにとってバランスをとるための行為です。アップグレードするにはソフトウェア アップデートを実行する必要がありますが、アップデート後もソフトウェアが新しいもののように見えません。

ユーザーは依然としてソフトウェアの現在のバージョンを使用しているため、最新バージョンに適応するのにほとんど時間や労力はかかりません。また、ユーザーが新機能の学習に時間を費やす必要も大幅に減ります。

この種のソフトウェア リリースでは、ユーザーが若干の変更嫌悪感に直面する可能性があります。たとえば、一部の UI オプションが調整された場合や、特定の新機能が気に入らなかった場合などです。

ただし、ほとんどの場合、マイナー リリースでは、エクスペリエンスの向上に大きな中断はありません。

マイナーバージョンのリリース

マイナー リリースはアップデートとも呼ばれ、メジャー リリースの上にインストールされます。つまり、ソフトウェアの現在のバージョンを編集します。

マイナー ソフトウェア リリースは、メジャー リリースよりも小さいです。これらは、ソフトウェア製品の全面的な見直しや新しいバージョンではありません。むしろ、既存の機能を強化および改善します。

したがって、マイナー リリースには次のものが含まれる可能性があります。

* 限定された新機能と機能

* 既存の機能の小規模なアップデート

* マイナーなバグ修正と継続的なセキュリティ パッチ

マイナー リリースは定期的に実行され、多くの場合バックグラウンドで実行されます。

マイナーリリースがユーザーにとって何を意味するか

マイナー リリースは、ユーザーに何らかの混乱をもたらす可能性があります。ただし、メジャー リリースほど影響力はありません。

マイナー リリースは、ソフトウェア ユーザーにとってバランスが取れたものです。アップデートの実行には時間がかかる場合がありますが、ソフトウェアが新しいように見えるほど大きな変更ではありません。

ユーザーは依然としてソフトウェアの現在のバージョンを使用しているため、最新のリリースに適応するために時間や労力はほとんど、またはまったく必要ありません。また、ユーザーが新機能の学習に時間を費やす必要が生じる可能性も大幅に低くなります。

このソフトウェア リリース タイプでも、ユーザーがマイナーな変更を嫌がる可能性があります。たとえば、特定の UI オプションに調整が加えられた場合や、新しい機能が気に入らない場合などです。

ただし、ほとんどの場合、マイナー リリースは、小規模な中断に対するエクスペリエンスの向上を意味します。

緊急解除

緊急リリースは「ホットフィックス」とも呼ばれます。

緊急リリースは、できるだけ早く解決する必要がある突然の問題または緊急の問題に対応します。彼らは次のことを解決するかもしれません:

• ソフトウェアの一部の動作を停止させる重大なバグ

• 最近発見された優先度の高いセキュリティ脆弱性

緊急リリースのポイントは、いくつかの緊急の問題を修正することです。これらは、ユーザー エクスペリエンスを大幅に向上させることを目的としたものではなく、ソフトウェアが効率的かつ安全に機能し続けることを保証することを目的としています。

緊急リリースは、直接修正される問題に対してのみ (目に見える) 影響を及ぼします。たとえば、機能 X がクラッシュしなくなったり、機能 Y がサイバーセキュリティ侵害でなくなったりします。

ユーザーは、バグやバグに関連して不便や中断を経験したことがあるかもしれません。あなたのサービスに対する信頼も低下している可能性があります。したがって、ユーザーにとって、緊急リリースは、物事が元の状態に戻るか、順調に進むことを意味します。

タイムリーな緊急リリースは、ユーザーが引き続きソフトウェアを効果的に使用できることを意味します。また、迅速かつ効果的に実行できれば、製品に対するユーザーの信頼を回復できます。

緊急ソフトウェアリリース

「ホットフィックス」として聞いたことがあるかもしれません。

緊急リリースは、できるだけ早く修正する必要がある突然の、または差し迫った問題が発生した場合に提供されます。彼らは次のことに取り組むかもしれません:

* ソフトウェアの一部が動作しなくなる重大なバグ

* 最近発見された優先度の高いセキュリティ脆弱性

緊急リリースのポイントは、何か緊急のものを修正することです。これらはユーザー エクスペリエンスを劇的に向上させるためではなく、ソフトウェアが効果的かつ安全に実行され続けることを保証するためにあります。

緊急リリースがユーザーにとって何を意味するか

緊急リリースは、直接修正される問題にのみ (顕著に) 影響を与えます。たとえば、X 機能はクラッシュしなくなり、Y はサイバーセキュリティ ホールを表しなくなりました。

ユーザーは、問題のバグや脆弱性により、不便や混乱を経験している可能性があります。あなたのサービスに対する信頼も低下している可能性があります。したがって、ユーザーにとって緊急リリースは、物事が正常に戻るか、順調に進むことを意味します。

したがって、迅速な緊急リリースは、ユーザーが引き続きソフトウェアを効果的に使用できることを意味します。また、迅速かつ適切に対処すれば、失われた製品の信頼を取り戻すこともできます。

要約する

メジャー リリース: 包括的な新しいアップグレード

マイナー リリース: 小規模な定期的なアップデート

緊急リリース: 突然の計画外のホットフィックス

また、ソフトウェアの新しいバージョンであっても、ソフトウェアの実行を継続するための重要な修正であっても、ソフトウェアのリリースはユーザーに影響を与えます。

したがって、今後の変化に向けて準備ができていることを確認してください。

メジャー: 大幅な新しいアップグレード

マイナー: 小規模な定期的なアップデート

緊急: 突然の計画外のホットフィックス

そして、それがソフトウェアの新しいバージョンであっても、動作を継続するための重要な修正であっても、ソフトウェアのリリースはユーザーに影響を与えます。

したがって、彼らが今後起こる変化に備えることができるようにしてください。

参考：

1. 異なるソフトウェア リリース間の違い

3 つのソフトウェア リリース タイプとユーザーにとっての意味 - Parker Software

2. バージョン番号の説明

バージョン内の数字は通常何を表しますか (つまり、v1.9.0.1)? - スタックオーバーフロー

3. Wiki バージョン番号の説明

https://en.wikipedia.org/wiki/Software_versioning

参考文献：

バージョン番号と互換性に関する注意

https://medium.com/fiverr-engineering/major-minor-patch-a5298e2e1798