build.numberがセマンティックバージョニングの「乱用」であるのはなぜですか？
提案されたビルドシステム（Gradle/Artifactory/Jenkins/Chef）を上級建築家の1人に説明していたところ、彼は私にコメントしました一種同意しないが、十分な経験がない本当に重荷です。
このプロジェクトは、他のチームが再利用するアーティファクトとしてJavaライブラリ（JAR）を構築します。バージョニングには、次のセマンティックアプローチを使用したいと思います。
<major>.<minor>.<patch>
ここで、patchはバグ/緊急修正を示し、minorは下位互換性のあるリリースを示し、majorはAPIの大規模なリファクタリングまたは下位互換性のない変更を示します。
ここでの配信に関する限り、私が望むのは、開発者がコードをコミットすることです。これにより、QA/TEST環境へのビルドがトリガーされます。一部のテストが実行されます（一部は自動化、一部は手動）。すべてのテストに合格した場合、プロダクションビルドはJARを社内リポジトリに公開します。この時点で、JARは適切にバージョン管理されているはずです。私の考えでは、build.numberパッチ番号として機能するCIツールによって自動的に生成および提供されます。
したがって、バージョン管理は実際には次のようになります。
<major>.<minor>.<build.number>
ここでも、build.numberはCIツールによって提供されます。
アーキテクトはこれを却下し、CIビルド番号の使用はセマンティックバージョニングの「乱用」であると述べました。
私の質問は、これは正しいですか、正しい場合、なぜですか？そうでなければ、なぜでしょうか？
ビルド番号は0にリセットされません。マイナーバージョンとメジャーバージョンが増えると、これは specs のセクション7および8に違反します。
マイナーバージョンY（x.Y.z | x> 0）は、新しい、下位互換性のある機能がパブリックAPIに導入されている場合はインクリメントする必要があります。パブリックAPI機能が非推奨としてマークされている場合は、インクリメントする必要があります。プライベートコード内に大幅な新機能または改善が導入された場合は、増加する可能性があります。パッチレベルの変更が含まれる場合があります。マイナーバージョンが増加する場合、パッチバージョンを0にリセットする必要があります。
メジャーバージョンX（X.y.z | X> 0）は、後方互換性のない変更がパブリックAPIに導入された場合、インクリメントする必要があります。マイナーおよびパッチレベルの変更が含まれる場合があります。メジャーバージョンが増加する場合、パッチとマイナーバージョンを0にリセットする必要があります。
したがって、バージョン番号（メジャー、マイナー、パッチ）は手動で提供する必要があります。これらは、変更ログやその他のドキュメントを見なくても、1か所での変更をユーザーに知らせるために使用されるためです。
ビルド番号を含める場合は、+（セクション10）の後に追加することができます。
ビルドメタデータは、パッチまたはプレリリースバージョンの直後に、プラス記号と一連のドットで区切られた識別子を追加することによって示すことができます。識別子はASCII英数字とハイフン[0-9A-Za-z-]のみで構成する必要があります。識別子を空にすることはできません。ビルドのメタデータは、バージョンの優先順位を決定するときに無視する必要があります。したがって、異なる2つのバージョンのみビルドメタデータの優先順位は同じです。例：1.0.0-alpha + 001、1.0.0 + 20130313144700、1.0.0-beta + exp.sha.5114f85。
1つの理由は、パッチに複数のビルドが必要になる可能性があるため、バージョン5.7があり、5.7.1にパッチを適用したいが、最初の2つのバグ修正がCIシステムに送信されたときにビルドに失敗した場合、最初のパッチをリリースする前の5.7.3
答えは、単純に4桁を使用することです（Microsoftシステムでは一般的です）。 4番目はビルド番号であり、「情報提供のみ」に使用されます。一般的に人々はそこにリポジトリのバージョン番号を入れます（SVNやTFSなどを使用している場合）。バイナリのビルドに使用された正確なコミットを確認できるので、これは本当に素晴らしいことです。そのようなものがない場合、CIビルド番号は妥当な概算です（CIシステムがビルド番号を記憶し、それをリポジトリの履歴に結び付けることを望んでいるが、CIに依存していないため）システムはそれらを記憶しています-古いビルドを削除することはできません）。
注意すべき点の1つは、バージョン管理用のMicrosoftスキーマはビルド番号の3番目の位置を使用することです。 Chromeは1つの数値のみを使用します。Ubuntuは日付を使用します。 使用する「標準」はありません ただし、すべての数値を増分する必要があります。