新しい開発を始める前、またはリリースにタグを付ける前にバージョンをバンプするのはどちらが良いですか？

新しい開発を開始する前にバージョンをバンプするプロジェクトもあれば、リリースにタグを付けるときにバージョンをバンプするプロジェクトもあります。

どちらのアプローチが優れていますか？

新しいフェーズの開始時にバージョン番号が変更されていない場合、開発者はバージョン番号を変更するのを忘れて、プログラムをリリースするだけです。

リリースにタグを付ける前にバージョン番号が変更された場合、バージョン番号（タグとMakefile / AssemblyInfo.cs）は一致しません。

git describe 現在のリビジョンがv1.2.3.4より後の場合、v1.2.3.4-15-g1234567が表示されることがありますが、ファイルはすでにv1.2.3.5に変更されています。

バージョン番号の主な理由は、バグが発見されたときに、エラーが実際に発生したソースコードの実際のバージョンを使用してデバッグできるようにするためです（したがって、バグの実際の理由を発見します）。

プロデュースのユーザーが開発者に十分な情報を伝え、開発者がこの目標を達成できる限り、どのバージョン管理スキームを使用してもかまいません。

バージョニングのその他の理由は、マーケティングおよびヘルプ（場合によっては合法）チームのためです。
これらのチームには、バージョン管理に関する独自の優先順位があります。

• ヘルプ
  互換性と機能、および場合によっては安定性を判断する簡単な方法が必要です（Linuxの奇数/偶数スキームを参照）。
• マーケティングでは
  毎回大きな数字が必要です（できれば2以上）
• 法務
  数を増やす前に、すべての機能がコミットされていることを確認したいと考えています。

すべての場合において、使用されるスキームは重要ではありません。一貫している（または意味の変更に関する非常に詳細なドキュメントを簡単に入手できる）限り。

.NETアセンブリのように4セグメントのバージョン番号を使用する場合は、バージョンコントロールタグを使用して最初の3つのセグメントを設定し、4番目のセグメントはそのタグ以降のコミットの数になります。

たとえば、バージョンには「v1.2.3」というタグが付けられます。git-describeが "v1.2.3-4-g1a2b3c4"を返す場合、ビルドすると、そのアセンブリは1.2.3.4としてバージョン付けされます。

タグが後でそのバージョンに適用されると、git-describeバージョン1.2.4.0を表す「v1.2.4」が返されます。次のコミットは1.2.4.1になります。

このシステムから得られる利点は次のとおりです。

• コミットごとに自動的にバージョン番号が増分されます。
• タグを付けるだけで、バージョンを「.0」リリースにすることができます。
• 完全ではありませんが、このシステムは最新のタグ以降のコミット数をカウントするため、DVCSで動作します。