更新バージョンとはどういう意味ですか？

多くのソフトウェアアップデートは、v0.1からv0.2からv2.6.5.6のスキームに従います。ソフトウェアに対するこれらの「更新」とはどういう意味ですか？業界標準が常に守られていますか、それともプログラマーは更新番号を上げ続けたり、小数点以下を追加したりしますか？

ショーンが言ったように、実際には標準はありません。一部の企業は、他の企業よりも優れたバージョン管理慣行を持っています（メジャーバージョン番号をスキップするベンダーや、後のリリースで同じxyにこだわっているベンダーを扱っています）。

そうは言っても、Gravatarsの発明者であり、GitHubの共同設立者（Tom Preston-Werner）は、「セマンティックバージョニング」のドキュメントを執筆しました。

イントロ以外は次のとおりです。

この問題の解決策として、バージョン番号の割り当て方法と増分方法を規定する簡単なルールと要件のセットを提案します。このシステムが機能するには、最初にパブリックAPIを宣言する必要があります。これは、ドキュメントで構成されているか、コード自体によって強制されます。とにかく、このAPIは明確で正確であることが重要です。パブリックAPIを特定したら、バージョン番号に特定の増分を加えて、変更を通知します。XYZ（Major.Minor.Patch）のバージョン形式を検討してください。APIに影響しないバグ修正はパッチバージョンを増分し、後方互換性のあるAPIの追加/変更はマイナーバージョンを増分し、後方互換性のないAPIの変更はメジャーバージョンを増分します。

このシステムを「セマンティックバージョニング」と呼びます。このスキームでは、バージョン番号とそれらの変更方法は、基礎となるコードと、あるバージョンから次のバージョンに変更されたものについての意味を伝えます。

4桁の場合、通常少なくともMajorV.MinorV.PatchNum.BuildNumです。

個人的には、Ubuntuのバージョン管理スキームを好みます。

短いバージョンは、標準がなく、企業は何でもしたいということです。基本的に、持っている数字が多いほど、各数字が表す変化の量は小さくなります。通常、少なくともバージョンxyが表示されます。xのxaの変更はメジャーリリース（メジャー拡張/機能のロールアウト）を意味し、yはマイナーリリース（重要な調整または不具合の修正）を意味します。これらの2つの後に小数点以下が増えると、会社にとって内部的に異なることを意味する場合がありますが、多くの場合、マイナーなコンテンツビルドまたはより迅速で小さな修正を表すパッチを中心に展開します。

ウィキペディアには、これについて詳しく説明した記事があります。

バージョン番号の目的は、問題レポートの参照を提供することです。唯一の要件は、すべてのリリースに一意のバージョン番号があることです。一部の数値はマーケティングに基づいており、大きな整数ほど販売が容易であり、10（ローマ数字X）のようなべき数値は本当にキャッチーです。一部の人々は、セマンティックバージョニングのいくつかのバリエーションを使用します。

メジャー、マイナー、マイクロ、ビルド

• 大幅な増加：互換性のない変更またはUIの完全な再設計
• マイナーインクリメント：新機能が追加され、同じメジャーバージョン番号の以前のバージョンと互換性があります
• マイクロインクリメント：バグ修正リリース
• ビルド番号：コンパイラーによって生成されるか、バージョン管理から取得されます

多くのグループは、リリースでBUILD番号を削除します。通常、テストグループと開発グループの間でのみ役立ちます。

一部のグループでは、追加のセマンティクスが追加されます。たとえば、奇数番号のマイナーインクリメントは実験ビルド用で、偶数番号のマイナーインクリメントは製品版リリース用です（Linuxカーネルはこのアプローチを使用します）。

一番下の行は、新しいバージョンがより高いバージョン番号を使用する以外、標準がなく、各バージョン番号が一意であることです。