Appバージョン番号の定義と説明の基礎知識

バージョン番号(version number)は、バージョンの識別番号です.各オペレーティングシステム(または一般的には、各ソフトウェア)にはバージョン番号があり、バージョン番号の定義ルールや現在のバージョン番号がどのような意味を表すか、オープンソースライブラリをアップグレードしたり、バージョン番号を設定したりするには、いくつかのあいまいな概念しかない可能性があるため、バージョン番号の定義に関する基礎知識を大まかに説明する必要があります.
バージョン管理の一般的な3つのネーミングフォーマット

GNUスタイルのバージョン番号命名フォーマットマスターバージョン番号.サブバージョン番号[.修正バージョン番号[.コンパイルバージョン番号]]例:1.2.1,2.0,5.0.0 build-13124

Windowsスタイルのバージョン番号命名フォーマット:マスターバージョン番号.サブバージョン番号[修正バージョン番号[.コンパイルバージョン番号]]例:1.21,2.0

Net Frameworkスタイルのバージョン番号命名フォーマット:マスターバージョン番号.セカンダリ・バージョン番号[.コンパイル・バージョン番号[.修正バージョン番号]]のバージョン番号は、プライマリ・バージョン番号、セカンダリ・バージョン番号、内部バージョン番号、およびリビジョン番号の2～4つのセクションで構成されます.プライマリ・バージョン番号とセカンダリ・バージョン番号は必須です.内部バージョン番号とリビジョン番号はオプションですが、リビジョン番号セクションが定義されている場合は、内部バージョン番号が必須です.定義されたすべての部分は、0以上の整数でなければなりません.

GNUバージョンの説明

        ：    .    .   ，         ：

        ：         API   

        ：              

       ：             

マスターバージョン番号:
メインバージョンは下向き互換性のないAPIの新規を表し、APPでは大バージョン更新プロジェクトの開発初期にAPIが不安定であった場合、一般的には0から、当該プロジェクトの共通APIが不安定であることを示し、随時変化する可能性がある.正式安定版、APP第1版は1からスタートし、プロジェクトに大きな変化が生じた場合はメインバージョン番号+、サブバージョン番号およびリビジョン番号はゼロになる
セカンダリ・バージョン番号:
マイナーバージョン番号表記は旧API対応の処理をしており、APPでは従来の機能の一部を追加した場合++、改訂番号はゼロになることを示している
改訂番号:
プロジェクトのバグ修正及び小範囲変更、APP同様
バージョン番号ルールの説明
通常の開発では、サードパーティのjarパッケージやcompileのオープンソースのlibraryを参照します.上記の説明により、参照するjarパッケージ、クラスライブラリのバージョン番号に基づいて、適切にアップグレードすることができます.例えば、第三者のライブラリxxx-2.1を引用すると、後期には安心して>=2.1、<3.0以内のすべてのバージョンを更新することができます.プライマリ・バージョン番号が変わらない場合は、セカンダリ・バージョン番号(下位互換の修正と新規)、リビジョン番号(バグの修正)を変更しただけで、互換性の問題は発生しません.プライマリ・バージョンには古いバージョンと互換性のない修正が追加されています.
セマンティックバージョンの説明