新しい開発を始める前にバージョンをバンプするか、リリースにタグを付けるときに、どちらが良いですか？
新しい開発を開始する前にバージョンをバンプするプロジェクトもあれば、リリースにタグを付けるときにバージョンをバンプするプロジェクトもあります。
どちらのアプローチが優れていますか？
新しいフェーズの開始時にバージョン番号が変更されていない場合、開発者はバージョン番号を変更するのを忘れて、単にプログラムをリリースすることがあります。
リリースにタグを付ける前にバージョン番号が変更された場合、バージョン番号（tagおよびMakefile/AssemblyInfo.cs）は一致しません。
git describe現在のリビジョンがv1.2.3.4以降であるが、ファイルをすでにv1.2.3.5に変更している場合、v1.2.3.4-15-g1234567が表示されることがあります。
バージョン番号の主な理由は、バグが発見されたときに、エラーが実際に発生したソースコードの実際のバージョンを使用してデバッグできるようにするためです（したがって、バグの実際の理由を発見します）。
プロデュースのユーザーが開発者に十分な情報を伝え、開発者がこの目標を達成できる限り、どのバージョン管理スキームを使用してもかまいません。
バージョニングのその他の理由は、マーケティングおよびヘルプ（場合によっては合法）チームのためです。
これらのチームには、バージョン管理に関して独自の優先順位があります。
- 助けて
互換性と機能、および場合によっては安定性を判別する簡単な方法が必要です（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で動作します。