Loading article…
ソフトウェアのバージョン管理とは、コンピュータソフトウェアの固有の状態に固有のバージョン名または固有のバージョン番号を割り当てるプロセスです。バージョン番号に最も広く採用されている方式はセマンティックバージョニング（SemVer）と呼ばれ、3つの部分からなるバージョン番号（メジャー、マイナー、パッチ）、オプションのプレリリースタグ（アルファ、ベータなど）、およびオプションのビルドメタタグで構成されます。Adobe Flashの場合のように、 4番目の番号を使用してソフトウェアのビルドを示すこともできます。一部の企業は、カレンダーバージョニングと呼ばれるシステムでビルド日を利用したり、Lotus 1-2-3 Release 1a のように文字やその他の記号を使用したりもします。
MediaWikiを含むほとんどのフリーソフトウェアやオープンソースソフトウェアでは、バージョンはピリオドで区切られた一連の個別の数値として扱われ、1.8.1、1.9.0のように進行します。一方、一部のソフトウェアパッケージでは、1.8、1.81、1.82のように小数でリリースを識別します。開発者は、重要な機能が追加されたことを示すため、またはマーケティング目的で、一度に複数のマイナーバージョンをジャンプすることを選択する場合があります。バージョン番号は、ソフトウェア製品のコピーを識別し、共同バージョン管理システムで別のコピーと比較するためによく使用されます。
ソフトウェア開発チームでは、バージョン管理は、情報の段階的なバージョンを追跡し、変更を元に戻せるようにするために使用されます。現代のコンピュータソフトウェアは、多くの場合、2つの異なるソフトウェアバージョン管理方式を使用して追跡されます。1つは内部バージョン番号で、1日に何度もインクリメントされる可能性があります。もう1つはリリースバージョンで、通常は変更される頻度がはるかに低くなります。
歴史的に、ファイル番号は特に公共行政や企業で、ファイルやケースを一意に識別するために使用されていました。この慣習は、MITのITSファイルシステムで初めてコンピュータファイルに導入され、その後1972年にPDP-10用のTENEXファイルシステムになりました。21世紀には、より多くのプログラマが、ソフトウェアライブラリ、フレームワーク、コマンドラインアプリケーションを使用する際に特に役立つセマンティックバージョニングポリシー[ 1 ]などの標準化されたバージョンポリシーを使用し始めました。
ファイル番号は、特に行政機関や企業において、ファイルや案件を一意に識別するために使用されていました。コンピュータファイルに関しては、この方法はMITのITSファイルシステムで初めて導入され、その後1972年にPDP-10用のTENEXファイルシステムが採用されました。[ 2 ]
その後、バージョンを含むファイルの一覧と、それらの間の依存関係が追加されました。Debian のような Linux ディストリビューションは、dpkgを使用して、パッケージ間の依存関係を解決できるパッケージ管理ソフトウェアを早期に作成しました。Debian の最初の試みは、パッケージが依存する他のパッケージを知っているというものでした。1994 年以降、このアイデアは逆転し、パッケージが自身に必要なパッケージを知っているという形になりました。パッケージをインストールする際には、依存関係解決を使用して必要なパッケージも自動的に計算し、目的のパッケージと一緒にインストールします。アップグレードを容易にするために、最小パッケージ バージョンが導入されました。そのため、番号付けスキームでは、どのバージョンが要求バージョンよりも新しいかを示す必要がありました。[ 3 ] [ 4 ] [ 5 ]
シーケンスベースのソフトウェアバージョン管理スキームでは、各ソフトウェアリリースに、1 つ以上の数字または文字のシーケンスで構成される一意の識別子が割り当てられます。[ 6 ]共通点はここまでで、シーケンスの数、個々のシーケンスの意味の割り当て、シーケンスのインクリメント方法などの領域ではスキームは大きく異なります。
一部の方式では、リリース間の変更の重要性を伝えるために、シーケンスベースの識別子が使用されます。変更は重要度レベルによって分類され、リリース間でどのシーケンスを変更するかは、前回のリリースからの変更の重要度に基づいて決定されます。つまり、最も重要な変更には最初のシーケンスが変更され、最初のシーケンス以降のシーケンスの変更は、重要度が低下する変更を表します。
スキームによっては、変更されたコード行数、追加または削除されたファンクションポイント、新バージョンの導入に必要な作業という観点からの顧客への潜在的な影響、バグや未発表の破壊的変更のリスク、ビジュアルレイアウトの変更度、新機能の数、あるいは製品開発者やマーケティング担当者が重要と考えるほぼすべてのもの（新バージョンの「相対的な優位性」を強調したいというマーケティング上の要望を含む）によって、重要性が評価される場合があります。
セマンティックバージョニング（別名 SemVer） [ 1 ]は、広く採用されているバージョンスキーム[ 7 ]であり、バージョンを 3 つの部分からなるバージョン番号 (メジャー、マイナー、パッチ)、オプションのプレリリース タグ、およびオプションのビルド メタ タグでエンコードします。このスキームでは、リスクと機能が重要度の尺度となります。破壊的変更はメジャー番号の増加によって示され (高リスク)、新しい非破壊的機能はマイナー番号の増加によって示され (中リスク)、その他のすべての非破壊的変更はパッチ番号の増加によって示されます (最低リスク)。プレリリース タグ (-alpha、-beta) の存在は、重大なリスクを示します。同様に、メジャー番号がゼロ (0.yz) の場合も重大なリスクを示します。これは、あらゆるレベルの潜在的に破壊的変更を含む可能性のある進行中の作業を示すために使用されます (最高リスク)。SemVer バージョンから互換性を推測する例として、API のバージョン 2.1.5 に依存するソフトウェアは、バージョン 2.2.3 と互換性がありますが、必ずしも 3.2.4 と互換性があるとは限りません。
4番目の数字は、Adobe Flashのようにソフトウェアのビルド番号を示すために使用される場合もあります。また、 Lotus 1-2-3 Release 1aのように、ビルド日や文字、その他の記号を含める企業もあります。
開発者は、重要な機能が追加されたが、メジャー バージョン番号を増やすほどではないことを示すために、一度に複数のマイナー バージョンをジャンプすることを選択する場合があります。たとえば、Internet Explorer 5の 5.1 から 5.5 またはAdobe Photoshop 5 から 5.5 です。これは、ソフトウェア ユーザーに対するアップグレードの価値を強調するため、または Adobe の場合のように、メジャー バージョン間の中間のリリースを表すために行われる場合があります (ただし、シーケンスベースのバージョン管理のレベルは、Blenderバージョン 2.91 やMinecraft Java Edition (1.7.10 から 1.21.11 まで) のように、必ずしも 1 桁に限定されるわけではなく、その後バージョン管理方式は年ベースの形式に移行しました)。[ 8 ]
別の方法として、メジャー番号とマイナー番号に加えて、リリースタイプを示す英数字文字列（例：「alpha」（a）、「beta」（b）、「release candidate」（rc））を使用する方法があります。この方法を用いたソフトウェアリリーストレインの例としては、0.5、0.6、0.7、0.8、0.9 → 1.0b1、1.0b2（いくつかの修正を含む）、1.0b3（さらに修正を含む）→ 1.0rc1（十分に安定している場合）、1.0rc2（さらにバグが見つかった場合）→ 1.0 などが挙げられます。この方式では、リリース候補フェーズ中に新機能や破壊的変更をロックアウトするのが一般的で、一部のチームでは、目標リリースへの収束を確実にするため、ベータ版でもバグ修正のみに限定しています。
他のスキームは、個々のシーケンスに意味を与える。
繰り返しますが、これらの例においても、「メジャー」な変更と「マイナー」な変更の定義は完全に主観的であり、著者次第です。同様に、「ビルド」の定義や、「リビジョン」と「マイナー」な変更の違いも、著者次第です。
LinuxおよびSolaris の共有ライブラリでは、 current.revision.age形式が使用される場合があります。[ 9 ] [ 10 ]
書籍出版においても、相対的な変更の重要性やバージョン管理の命名法に関する同様の問題が存在し、版番号や版名はさまざまな基準に基づいて選択される可能性がある。
ほとんどの独自ソフトウェアでは、ソフトウェア製品の最初のリリースバージョンはバージョン1です。
一部のプロジェクトでは、互換性のないリリースを示すためにメジャーバージョン番号を使用しています。例として、Apache Portable Runtime (APR) [ 11 ]と FarCry CMS [ 12 ]が挙げられます。
プログラマーは、後方互換性を持たせるために新しいソフトウェアを作成することがよくあります。たとえば、IBM z/OS は、同じシスプレックスで実行されているオペレーティングシステムの 3 つの連続したメジャー バージョンで正しく動作するように設計されています。これにより、高可用性コンピュータ クラスタを運用しているユーザーは、一度に 1 台のマシンをシャットダウン、アップグレード、およびサービスに復元している間も、ほとんどのコンピュータを稼働状態に保つことができます。[ 13 ]
パケットヘッダーやファイル形式にはバージョン番号が含まれていることが多く、その番号は作成元のソフトウェアのバージョン番号と同じ場合もあれば、ソフトウェアのバージョン番号とは無関係な「プロトコルバージョン番号」である場合もあります。古い非推奨のプロトコルやファイル形式を処理するためのコードは、しばしば不要なコードと見なされます。
実験段階（アルファ版またはベータ版）のソフトウェアでは、その状態を示すためにシーケンスの最初の（「メジャー」）位置にゼロを使用することがよくあります。ただし、この方式は初期段階でのみ有効であり、バージョン番号がすでに0を超えている確立されたソフトウェアの今後のリリースには適していません。[ 1 ]
新しいリリースのステータスを示すために、いくつかの方式が用いられています。
純粋に数値のみで構成されるこの2つの形式は、セマンティックバージョニングに見られる「alpha < beta < rc <接頭辞なし」の比較を処理するために必要な特別なロジックを排除するが、その分、明瞭さが損なわれる。
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 進数で識別します。10 進数バージョンは、NetWare、DOS、Microsoft Windowsなど 1980 年代に一般的でしたが、2000 年代でもOpera [ 14 ]やMovable Typeなどで使用されています。[ 15 ] 10進数表記では、1.81は1.8に続くマイナーバージョンであり、メンテナンスリリース（つまりバグ修正のみ）は1.81aや1.81bのようにアルファベットの接尾辞で示される場合があります。
標準的なGNUバージョン番号付けスキームは major.minor.revision ですが[ 16 ] 、 Emacs は別のスキームを使用している注目すべき例で、メジャー番号 (1) が削除され、ユーザーサイトのリビジョンが追加されています。これは、オリジナルの Emacs パッケージでは常にゼロですが、ディストリビューターによって増加されます。[ 17 ]同様に、Debianパッケージ番号にはオプションの「epoch」が接頭辞として付いており、これによりバージョン付けスキームを変更できるようになります。[ 18 ]
場合によっては、開発者がメジャーバージョン番号をリセットすることを決定することがあります。これは、新しい開発フェーズがリリースされたことを示すために使用されることがあります。たとえば、Minecraft Alpha はバージョン 1.0.0 から 1.2.6 まで実行され、Beta がリリースされたときにメジャーバージョン番号がリセットされ、1.0 から 1.8 まで実行されました。ゲームが完全にリリースされると、メジャーバージョン番号は再び 1.0.0 にリセットされました。[ 19 ]
プロジェクトによっては負のバージョン番号を使用するものもあります。例えば、SmartEiffelコンパイラは-1.0から始まり、0.0までカウントアップします。[ 17 ]
ソートを容易にするため、一部のソフトウェア パッケージでは、メジャー.マイナー.リリーススキームの各コンポーネントを固定幅で表現します。Perl はバージョン番号を浮動小数点数で表現します。たとえば、Perl の 5.8.7 リリースは 5.008007 と表現することもできます。これにより、理論上のバージョン 5.8.10 を 5.008010 と表現できます。他のソフトウェア パッケージでは、各セグメントを固定ビット幅にパックします。たとえば、Microsoft Windows では、バージョン番号 6.3.9600.16384 は16 進数0x0006000325804000 と表現されます。浮動小数点スキームは、バージョン番号のいずれかのセグメントが 999 を超えると破綻します。16 ビットずつ使用するパック バイナリ スキームは 65535 を超えると破綻します。
Linuxカーネルは、1.0から2.6.xシリーズまでの間、奇数のマイナーバージョン番号を開発版リリース、偶数のマイナーバージョン番号を安定版リリースとして使用していました。例えば、Linux 2.3はLinuxカーネルの2番目のメジャー設計の開発版であり、Linux 2.4はLinux 2.3が成熟した安定版リリースでした。Linuxカーネルのマイナーバージョン番号の後には、リリース番号が昇順で続きます。例えば、Linux 2.4.0 → Linux 2.4.22となります。2004年に2.6カーネルがリリースされて以来、Linuxはこのシステムを使用しなくなり、リリースサイクルは大幅に短縮されました。
同じ奇数偶数システムは、Node.js（バージョン0.12まで）やWineHQなど、リリースサイクルが長い他のソフトウェアでも使用されています。[ 20 ]
多くのプロジェクトでは、カレンダーバージョン管理（別名CalVer [ 21 ] ）と呼ばれる日付ベースのバージョン管理スキームを使用しています。
Ubuntuは、カレンダーによるバージョン管理を採用しているプロジェクトの一例です。例えば、Ubuntu 18.04は2018年4月にリリースされました。この方式の利点は、開発スケジュールやサポート期間との関連付けが容易であることです。ビデオゲームの中にも、日付をバージョン管理に使用しているものがあります。例えば、アーケードゲームのストリートファイターEXなどがそうです。起動時に、バージョン番号が日付と地域コードの組み合わせで表示されます。例えば、961219 ASIAのように表示されます。
ファイル名などのバージョン管理で日付を使用する場合、ISO 8601スキーム[ 22 ] YYYY-MM-DDを使用するのが一般的です。これは、文字列を昇順または降順に簡単にソートできるためです。ハイフンは省略されることがあります。Wineプロジェクトでは以前、リリースされた年、月、日の順を使用する日付バージョン管理スキームを使用していました。たとえば、「Wine 20040505」です。Minecraftの初期の開発ビルドは同様のバージョン形式でしたが、代わりに DDHHMM を使用していました。たとえば、rd-131655 は 2009 年 5 月 13 日 16:21 に作成されました。
Microsoft Office のビルド番号はエンコードされた日付です。[ 23 ]最初の 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 としてバージョン付けされています。[ 24 ]
ソフトウェア開発者の中には、ソフトウェアのリリースを示すために異なる方式を使用しているところもあります。Debianプロジェクトは、オペレーティングシステムのリリースにメジャー/マイナーバージョン方式を使用していますが、開発中は映画「トイ・ストーリー」のコードネームを使用して、安定版、不安定版、テスト版を区別しています。[ 25 ]
BLAG Linux と GNU は非常に大きなバージョン番号を特徴としています。メジャー リリースには 50000 や 60000 などの番号が付けられ、マイナー リリースでは番号が 1 ずつ増加します (例: 50001、50002)。アルファ リリースとベータ リリースには、メジャー リリース番号よりわずかに小さい 10 進数のバージョン番号が付けられます。たとえば、バージョン 20000 のアルファ 1 には 19999.00071、バージョン 30000 のベータ 2 には 29999.50000 が付けられます。[ 26 ] [ 27 ] [ 28 ]
Urbitはケルビンバージョン管理（絶対ケルビン温度目盛にちなんで名付けられた）を採用しており、ソフトウェアのバージョンは高い番号から始まり、バージョン0までカウントダウンされ、その時点でソフトウェアは完成とみなされ、それ以上の変更は行われません。[ 29 ] [ 30 ]
上記に挙げた様々なバージョン管理方式と併せて、ソフトウェアリリースライフサイクルの各段階を経てプログラムが進むにつれて、プレリリースバージョンを示すシステムが一般的に使用されます。
開発初期段階のプログラムは、ギリシャ語アルファベットの最初の文字にちなんで「アルファ版」ソフトウェアと呼ばれることが多い。成熟しつつもまだリリース準備が整っていないプログラムは、ギリシャ語アルファベットの2番目の文字にちなんで「ベータ版」ソフトウェアと呼ばれることがある。一般的に、アルファ版ソフトウェアは開発者のみがテストを行うのに対し、ベータ版ソフトウェアはコミュニティによるテストのために配布される。
一部のシステムでは、最終的な「1.0」リリースに向けたアプローチを示すために、1未満の数値バージョン（0.9など）を使用します。これはオープンソースソフトウェアで一般的な慣習です。[ 31 ] [ 32 ]ただし、プレリリースバージョンが既存のソフトウェアパッケージ（バージョン2.5など）用である場合は、バージョン番号に「a」または「alpha」が付加されることがあります。したがって、2.5リリースのアルファバージョンは2.5aまたは2.5.aとして識別される可能性があります。
別の方法として、プレリリース版を「リリース候補版」と呼ぶ方法があります。つまり、特定のバージョンとしてまもなくリリースされるソフトウェアパッケージには、そのバージョンタグの後にリリース候補版の番号を示す「rc-#」が付加されます。最終バージョンがリリースされると、「rc」タグは削除されます。
バージョン番号は、実際には、消費者（クライアント）がソフトウェア製品の自分のコピーを、開発者がリリースした最新バージョンなどの別のコピーと識別または比較するために使用されます。プログラマーや企業にとっては、バージョン管理は多くの場合、改訂版ごとに使用され、ソフトウェアの個々の部分が、同じ部分の新しいバージョンまたは古いバージョンと比較検討されます。これは多くの場合、共同バージョン管理システムで行われます。
21世紀に入り、セマンティックバージョニングポリシーなどの形式化されたバージョンポリシーを使用するプログラマが増えました。[ 1 ]このようなポリシーの目的は、コードの変更によって自分が書いたものが壊れる可能性がある場合を他のプログラマが簡単に把握できるようにすることです。このようなポリシーは、ソフトウェアライブラリやフレームワークにとって特に重要ですが、コマンドラインアプリケーション（他のアプリケーションから呼び出される可能性がある）やその他のアプリケーション（サードパーティによってスクリプト化および/または拡張される可能性がある）にも非常に役立つ可能性があります。
ソフトウェアリリーストレインとは、複数の製品向けにバージョン管理されたソフトウェアリリースの複数のシリーズを、複数の異なる「トレイン」として定期的にリリースするソフトウェアリリーススケジュールの形式です。一般的に、各製品ラインごとに複数のリリーストレインが同時に稼働しており、各トレインは計画されたスケジュールに従って、初期リリースから最終的な成熟、そして廃止へと移行します。ユーザーは、本番環境に導入する前に新しいリリーストレインを試用することができ、新しいリリーストレインが成熟するまで、本番システムでは以前のトレインのポイントリリースを引き続き適用しながら、より新しい「生」のリリースを早期に試用することが可能です。
Cisco のIOSソフトウェア プラットフォームは、長年にわたり、多数の異なるリリース トレインを持つリリース トレイン スケジュールを使用していました。最近では、Firefoxや Android 用の Fenix [ 33 ] 、 Eclipse [ 34 ] 、 LibreOffice [ 35 ] 、Ubuntu [ 36 ]、Fedora [ 37 ] 、 Python [ 38 ] 、 digiKam [ 39 ] 、 VMware [ 40 ]など、他の多くのプラットフォームがリリース トレイン モデルを採用しています。
ソフトウェアには、製品名に表示されるバージョン番号とは異なる「内部」バージョン番号が存在する場合があります（そして、通常はバージョン番号の規則に一貫して従っています）。たとえば、Java SE 5.0 の内部バージョン番号は 1.5.0 であり、Windows NT 4 以降のバージョンでは、内部的に標準的な数値バージョンが継続されています。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 は当初 NT 6.4 となる予定で、一般に公開された最初のテクニカル プレビュー ビルドは 6.4.9841 という番号が付けられています。しかし、それは長くは続かず、Windows 10 のバージョンは商用名に合わせるためにすぐに人為的に 10.0 [ 41 ]に引き上げられ、その結果、オペレーティングシステムの最初のリリースバージョンは 10.0.10240 という番号になりました。ただし、Windows NT はまだ 5 番目のメジャー改訂版であり、最初のリリースは (当時の Windows リリース番号に合わせるため) 3.1 という番号で、Windows 10 のリリースではバージョンが 6.3 から 10.0 に飛躍したことに注意してください。
マーケティング上の理由から、バージョン番号を大きく上げることは比較的よくあることです。ソフトウェアベンダーは、1.0 リリースをスキップしたり、後続のバージョン番号でリリースをすぐに開始したりすることがあります。これは、多くの顧客が 1.0 ソフトウェアを本番環境での導入にはまだ未熟だと考えているためです。例えば、dBase IIの場合のように、実際よりも成熟しているように見せかけるバージョン番号で製品が発売されることがあります。
また、競合他社のバージョン番号に合わせるために、バージョン番号が引き上げられる場合もあります。これは、Microsoft、 America Online、Sun Solaris、Java Virtual Machine、SCO Unix、WordPerfectなどの製品のバージョン番号の例に多く見られます。Microsoft Accessは、 Microsoft Wordのバージョン番号に合わせるため、バージョン2.0からバージョン7.0にジャンプしました。
Microsoft も「追いつき」バージョンアップの標的となっており、Netscapeブラウザは Microsoft のInternet Explorerに合わせてバージョン 5 から 6 に飛びましたが、これは Mozilla アプリケーション スイートが1.0 以前の開発中にユーザー エージェントストリングでバージョン 5 を継承し、Netscape 6.x が Mozilla のコード ベースに基づいて構築されたためです。競合他社に追いつくもう 1 つの例は、Slackware Linux が 1999 年にバージョン 4 からバージョン 7 にジャンプしたことです。 [ 42 ]
このアプローチは、バージョン番号の各セクションの意味的な意義を損なうため多くの人から批判されているが、 Mozilla ( Firefox用) やGoogle ( Google Chrome用)など、ますます多くのベンダーに採用されている。[ 43 ]
SunのJavaは、内部バージョン番号が常に1.xであるにもかかわらず、 xのみを参照して販売されるというハイブリッドシステムを採用していた時期がありました。
サン・マイクロシステムズはまた、Solarisの名称の最初の数字を削除し、マーケティング資料ではSolaris 2.8（または2.9）をSolaris 8（または9）と表記している。
同様の飛躍は、2010年代初頭にオープンソースのPBX構築キットであるAsteriskでも起こり、プロジェクトリーダーは現在のバージョン1.8.xに続いてバージョン10が間もなくリリースされると発表した。[ 44 ]
フリーソフトウェアやオープンソースのコミュニティは、ソフトウェアを早期かつ頻繁にリリースする傾向があります。初期バージョンは 1 未満の番号で、これらの 0.x バージョンは、ソフトウェアが未完成で、一般公開するには信頼性が十分ではなく、現状では使用できないことを示すために使用されます。0.x バージョンでは、後方互換性のない変更がよく発生します。バージョン 1.0 は主要なマイルストーンとして使用され、ソフトウェアが少なくともすべての主要な機能と開発者がそのバージョンに含めたい機能を備えており、一般公開するには信頼性が十分であると見なされていることを示します。[ 31 ] [ 32 ]この良い例は Linux カーネルで、1991 年にバージョン 0.01 として最初にリリースされ、[ 45 ] 1994 年までバージョン 1.0.0 に到達しませんでした。[ 46 ]
アーケードゲームエミュレータMAMEの開発者は、エミュレートすべきアーケードゲームが常に増え続けるため、プロジェクトが真に完成することはないと考え、プログラムのバージョン1.0をリリースするつもりはない。そのため、バージョン0.99に続いてバージョン0.100がリリースされた。[ 47 ]
Python Software Foundationは、PEP 440 – バージョン識別と依存関係仕様[ 50 ]を公開し、エポックセグメント、リリースセグメント、プレリリースおよびポストリリースセグメント、開発リリースセグメントを定義する独自の柔軟なスキームの概要を示しました。
TeX には独特なバージョン番号付けシステムがあり、これは開発者のDonald Knuthが考案した珍しい機能です。バージョン 3.1 以降、更新は末尾に桁を追加することで示され、バージョン番号は漸近的にπに近づきます。つまり、意味論的バージョン管理では 3.14 は実質的に 3.2 を意味します。（これは単項番号付けの一種で、バージョン番号は桁数です。）2021 年以降、バージョン番号は 3.141592653 となっています。これは TeX が非常に安定しており、マイナー アップデートのみが予定されていることを反映しています。TeX 開発者の Donald Knuth は、「（彼の死後に行われる）絶対的に最後の変更」はバージョン番号をπに変更することであり、その時点で残っているすべてのバグは恒久的な機能になると述べています。[ 51 ]
同様に、Metafontのバージョン番号は漸近的にオイラー数eに近づきます。[ 51 ] 2021 年 2 月現在、バージョン番号は 2.71828182 です。Metafont は、ドナルド・クヌースが自身の TeX 組版システムの補助として考案したものです。
クラシック Mac OSの時代には、マイナー バージョン番号が「.1」を超えることはめったにありませんでした。超えた場合でも、通常は「.5」に直接ジャンプし、そのリリースが「より重要なもの」であることを示唆していました。[ a ]そのため、「8.5」は「Mac OS 8 と 1/2」を表す独立したリリースとして販売され、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」ベースのバージョン付け方式では、3 番目の番号（2 番目の番号ではなく）がマイナーリリースを示し、このレベル以下の追加のアップデート、および新しいメジャーバージョンのリリース後にリリースされる特定のメジャーバージョンの OS X のアップデートは、補足アップデートと呼ばれた。[ 52 ]
ローマ数字の 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」が削除され (下記参照)、QuickTime のブランディングは 2011 年にフレームワークが AVFoundation に置き換えられた際に意味を失いました (QuickTime ビデオを再生するプログラムは、当初から QuickTime Player という名前でした)。
Appleの次期macOSリリースは、暫定的に10.16と番号が付けられており[ 53 ]、2020年6月のWWDCでmacOS 11として正式に発表され、2020年11月にリリースされました[ 54 ]。次のmacOSバージョンであるmacOS Montereyは、2021年10月にリリースされ、メジャーバージョン番号が12に上がりました[ 55 ]。
2025年6月、Appleは自動車のモデルイヤーと同様に、リリース日の横に年を付ける統一バージョン表記法を発表しました。2025年秋にリリースされたバージョンは、iOS 26、macOS 26、iPadOS 26、tvOS 26、watchOS 26、visionOS 26です。 [ 56 ]
Microsoft Windowsオペレーティングシステムは、最初はWindows 1.01からWindows 3.2まで標準バージョン番号でラベル付けされていました。その後、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 7、Windows 8、Windows 8.1のバージョン番号はそれぞれ 6.1、6.2、6.3 です。Windows 10では、バージョン番号が 10.0 [ 57 ]に跳ね上がり、その後の OS のアップデートでは、ビルド番号 (日付ベース) とアップデートビルドリビジョン (UBR) 番号のみが増加しました。
Windows 10 の後継であるWindows 11は、2021 年 10 月 5 日にリリースされました。「11」という名前が付けられていますが、新しい Windows リリースではメジャー バージョン番号が 11 に更新されませんでした。代わりに、Windows 10 で使用されていたバージョン番号 10.0 のままでした。[ 58 ]
OpenVMSファイルシステムなど、一部のコンピュータファイルシステムでは、ファイルのバージョンも管理されています。ドキュメントのバージョン管理は、コンピュータやソフトウェアエンジニアリングで使用されるルーチンと比較的似ており、構造、内容、または条件に小さな変更を加えるたびに、バージョン番号が1ずつ、またはそれより小さい値もしくは大きい値ずつ増加します。この増加量は、作成者の個人的な好みや、行われた変更の規模や重要性によって異なります。
技術図面やCADソフトウェアファイルでは、変更履歴を追跡するために、何らかの原始的なバージョン番号が使用される場合もある。
各リリースは、メジャー バージョンとマイナー バージョンという 2 つのバージョン番号で識別する必要があります。2 つ以上の番号を使用することに異論はありませんが、実際にそれらが必要になる可能性は非常に低いでしょう。