ビルドはタグを駆動する必要がありますか、それともタグがビルドを駆動する必要がありますか？
製品リリースを作成する現在の方法は、すべてのコンポーネントリポジトリに次の適切なバージョンのタグを付けてから、各コンポーネントのこれらの新しいバージョン番号でマスタービルドスクリプトを変更することです。次に、マスタービルドスクリプトが実行され、各コンポーネントのSCMチェックアウトが実行されます。次に、コンパイルされた.exe（または.dll）のバージョン番号が正しいようにAssemblyInfo.csファイルが変更され、コンポーネントがコンパイルされます。次に、これらのコンポーネントはすべて合体して製品リリースになり、純粋なマーケティング決定番号で「バージョン管理」されます。
したがって、私たちのプロセスは「タグがビルドを駆動する」という説明に該当しますが、それが最善の方法かどうかはわかりません。具体的には、これが失敗していると思うのは、リリースビルドをCIプロセスに統合する場合、逆行するようです。
それだけでなく、一般的なリリース管理プロセスのどこで、新しいコンポーネントのバージョン番号の決定が行われますか？コンポーネントAが2.1.4から3.0.0に移行する時期と、ライブラリBを6.3.2から6.3.3または6.4.0に変更するかどうかを誰かが決定する必要があります。これらのバージョン番号はどこに保存され、どの段階で決定されますか？現在、これらの決定は「最後の瞬間」に行われ、マスタービルドスクリプトに保存されます。マスタービルドスクリプト自体はバージョン管理されており、「マーケティング」バージョン番号でタグ付けされています。
私が使用しているシステムには、メジャーバージョン番号とマイナーバージョン番号を含むバージョン番号ファイルがあります。CIサーバーは、このファイルへのチェックインされた変更を使用して、「リリース」ビルドをトリガーします。 CIサーバーは、ビルド番号を追加してmajor.minor.buildバージョンを作成し、そのビルドに使用されるコードにタグを付けます。
製品のリリースサイクル、パッチアプローチなどに応じて、さまざまな正解があります。
現在作業している領域では、RCビルドに増分整数のタグを付けます。 CIスタイルのビルドはバージョン管理されません。マーケティング側で何が起こっているのかわかりません。 :-)
セマンティックバージョニング バージョンをいつバンプするか、何にバンプするかを特定するのに役立ちます。
いくつかの重要なポイント：
- 後方互換性のない変更は、メジャーバージョンのバンプを取得します（
3.2.9->4.0.0）。 - 下位互換性のある機能の追加/変更により、マイナーバージョンのバンプが発生します（
3.2.9->3.3.0）。 - 下位互換性のあるAPIを変更しないバグ修正は、パッチレベルのバージョンバンプを取得します（
3.2.9->3.2.10）。
私たちが通常行う方法は、意味のある名前で分岐して、それが何であるかを認識し、最終リリースとして増分バージョン番号でタグ付けすることです。小さな変更（1.2-> 1.3）の場合は小さい増分、大きな機能の場合は大きい増分（1.0-> 2.0）。
「タグがビルドを駆動する」は、開発/テスト/ QA /リリースサイクルのすべての段階で理解して使用するのが簡単なので、一般的には良いシステムだと思います。ビルドスクリプトにタグをフィードしている場合は、「ビルドx.y」が次のステップの準備ができていると意図的に言っています。
CIプロセスから得られるビルド番号も役立ちますが、同じ猶予で変更情報をキャプチャできない可能性があります。これは、2.3.5または23432ですか？
使用するラベリングのパブリックシステムに関係なく、デバッグ/レポートの目的で詳細なバージョン情報にアクセスできることを確認してください-バージョン番号、CIビルド番号、ソース管理リビジョン番号、ビルド日時-必要なデータは何でも扱っているビルドを正確に特定します。
決定点に関しては、はい、最終的には恣意的であり、うまくいくものは何でもあります。 @Justiceが言及しているセマンティックバージョニングシステムは素晴らしいです。重要なことは、次に使用するバージョン番号を決定するときに、チームがかなり使いやすいシステムを考え出すことができる必要があるということです。