リリースブランチとトランクのバージョン管理
次の形式のバージョンを使用しています。
Major.Minor.Bugfix.Test
トランクでは、次期リリースの開発が進んでいます。十分な機能が完成したら、1.1、1.2などの新しいリリースブランチを作成します。
ブランチが作成された後、継続的な「安定化」プロセスがあり、ブランチのテストバージョン1.1.0.1、1.1.0.2などが生成されます。新しいバグ修正バージョンの準備ができるまで、これらは次のとおりです：1.1.1 、1.1.2など。
以下の画像はそれをよりよく説明するはずです：
リリースブランチを作成すると、トランクのバージョンが増加します（次のリリースに向けて何らかの形で作業を開始するため）。
問題：トランクでバージョンを使用する必要もあります（これらは内部テスト用に提供されています）。次のリリースのブランチテストバージョン（赤い丸でマークされています）と衝突します。
質問：このようなバージョンの衝突を回避する方法は？
1つの提案は、分岐後にトランクバージョンを十分な数に変更することでした。 1.2.0.100、これは衝突を起こしにくくしますが、醜いです。
理想的には、数値を「小さく」維持したい（覚えやすく、使いやすい）。
（オプション）別のこと：現在のリリースブランチからトランクに定期的にマージした後、バージョンでもこれを何らかの形で示すことは意味があります（図で？含まれている、例えば1.1.1.1をトランク（現在は1.2.0.3）にマージした後、1.2.0.4をインクリメントするだけでなく、バージョンでも何かが発生するはずです。何だかわかりません。
アイデア？
概要をわかりやすくするために、提案されたソリューションの1つの画像を次に示します。
アイデアは、リリースブランチの番号を継承（継続）することです。これは衝突を解決しますが、もう1つの問題を引き起こします：1.1または1.2バージョンはもうありません。できれば持っておきたいです。
他の回答者のおかげで、バージョン管理システムについて最終的に合意しました。
テストバージョンをリリース番号で開始することを目的としています（たとえば、1.1.0.1は「1.1.0 releaseのテストバージョン」を意味します）。テストが終了するとremoveTestになります。
通常、バージョンは成長しています
1.1.1 --- 1.1.0.1 --- 1.1.0.2 --- 1.1.0.3 --- ... --- 1.2
そして、startを別の方法で行い、最後にresetを実行します
1.1.1 --- 1.2.0.1 --- 1.2.0.2 --- 1.2.0.3 --- ... --- 1.2
画像：
- リリースブランチバージョンはトランクのバージョンから継続されます。
- トランクのバージョンはreset to
x.x.0.1になります。 - リリース後、テストバージョンは
x.x.x.1にリセットされます。ここで、x.x.xは次のリリースバージョンです。 - リリースバージョンは、
Test番号をクリアすることで取得されます（「テストが終了した」ことを意味します）。
両方の問題に対処する2つの主要な戦略があります。
1.トランクには「固定」バージョン番号があります
トランクにバージョン番号0.0.0.Xを付けることを選択できます。この場合、Xのみが変更されます。これにより、そのようなビルドはアクティブな開発の一部であり、リリースの安定化の一部ではないことが誰にでも明らかになります。
この概念では、以前のリリースのバグ修正がトランクにマージされているときに（バージョン番号を使用して）追跡することは意味がありません。
また、安定化を開始するときに、リリースするバージョン番号を決定するだけでよい（マイナーまたはメジャー部分をインクリメントする）ことにも利点があります。
2.リリースブランチはTrunkが終了したところに続きます
作業方法を現在実行している方法にできるだけ近づけたい場合は、リリースブランチでテスト番号を続けるだけです。
1.2リリースブランチを作成することを決定したときにTrunkがバージョン1.2.0.26である場合、そのリリースブランチの最初のビルドは1.2.0.27になります（次のビルドはTrunk 1.3.0.1になります）。
このスキームでは、以前のリリースのバグ修正をマージするときに、TrunkのバージョンのBugFix部分をインクリメントできます。
このスキームは本質的に枝の異なる精神的画像を使用しています
------------------------ release 1.1
\
\----------------- release 1.2
\
\---------- trunk (to become release 1.3)
リリースの安定化を開始するときは、Trunkの名前をリリースブランチに変更し、次のリリースの開発のためにその時点から新しいTrunkを作成します。
トランクが1.3.0.3であるとしましょう。ここで、「1.3」行のリリースブランチを作成します。つまり、ブランチはその番号1.3.0.で始まります。同時に、トランクを1.4に設定します。
「リリース」ブランチでの安定化プロセスは、1.3.0.4、1.3.0.5、1.3.0.6、場合によっては「1.3.1」などのようにインクリメントします。「major.minor」の数値は常に固定されます。
一方、トランクのバージョンは1.4.0.1、1.4.0.2などになります。そのため、トランクには、他のすべてのリリースブランチよりも常に「major.minor」番号が大きくなります。つまり、衝突はありません。
リリースブランチの変更をトランクにマージする場合は、トランクを直接変更するのと同じように、トランクのバージョン番号を増やします。 VCS（TFS）は、どのリビジョンから変更をトランクにマージしたかを文書化することをサポートしている場合があります。そうでない場合は、いつでもこれを履歴ログに手動で書き込むオプションがあります（単に「1.3.0.6から次の変更をマージトランクに戻る：... "）。そしてそれはそれが属する場所です、私はそのような情報をバージョン番号にマッピングしようとはしません。
このために私が思いついた2つのソリューション：
Bart van Ingen Schenauの「トランクが終了したところにリリースブランチが続く」という提案に従って-基本的に現時点で行っていることと同じですが、リリースブランチを作成するときにバグ修正をリセットし、リリース番号のコンポーネントをテストしません。 。
Linuxカーネルのバージョン管理方法と同様に、リリースブランチを作成する前と作成した後の両方で、マイナーバージョンをバンプします。これは、特定のマイナーバージョン番号がトランクまたはリリースブランチに存在するが、両方には存在しないことを意味します。 Linuxカーネルがこのように番号付けされなくなった正確な理由はわかりませんが、問題が発生した可能性があります。
ゼロ+非リリースブランチの連結
私は常にTrunkのような非リリースブランチを0で開始し、リリースメジャーとマイナーをトランクマイナーとして連結することによって、一般的に次のリリース番号の周りにそれを維持しようとします。したがって、現在のリリースが7.6.1で次のリリースが7.7.1の場合、トランクは0.77.1になります。 3つの部分は重要なものではなく、4つ目の部分は自動インクリメント部分として省略しているだけです。ソース管理のコードは7.7.1.0または0.77.1.0になります。
この「ゼロ+連結」は、開発/アルファアーティファクトを生成する可能性があり、コードの「時代」を識別するためのリリース番号に比較的十分近い、衝突しないトランクバージョン番号を私に与えます。
ブランチのバージョニングを停止する
「ブランチのバージョン管理」や、コードのバージョン番号を絶えず更新することに伴うすべてのコード管理チャーンに対処することについて、それほど心配する必要はないと思います。
バージョン番号は、ブランチを構成する生のソースコードではなく、プログラムやその他のコンパイル済みコードアーティファクトに割り当てられます。予想されるリリース番号のブランチに名前を付けることもありますが、トランクをバンプする場合やリリースブランチをバンプする場合（またはブランチの作成時に設定する場合）を除き、ソースコードにバージョンを設定しません。ビルドプラットフォームに番号付けの増分を処理させます（それは.1で始まるはずです）。ビルドプラットフォームもmustタグを付けるか、そのバージョンのビルドに組み込まれた特定のコードチェンジセット/コミットにラベルを付けます。
上記の例を使用すると、リリースブランチのコードには7.7.1.0がアセンブリのバージョン管理として設定され、ビルドプロセスはコードを取得して、バージョンを7.7.1.1に設定します。 7.7.1.2。などとコンパイル。
リリースのバグ修正/ホットフィックスはマージされ、リリースビルドが実行され、問題を解決するために必要なパーツ（dllなど）だけがテスト用の修正としてパッケージ化されます。
バージョニングはアーチファクトの識別に役立ちます
なぜバージョン管理するのかを思い出してください。デプロイされたソフトウェアをより確実に識別できるようにして、それらのサポートとメンテナンスを改善します。作成するためだけにバージョン管理することはありません別の管理するもの。
したがって、これはアーティファクトを生成するビルドにのみ適用されます。機能のブランチなどは、ゲートチェックインまたは同様のビルドのみを必要とすることが多いため、通常これに該当しません。フィーチャーブランチのアーティファクトを作成する必要がある場合でも、メジャーは0、連結はマイナーですが、衝突の現実的な可能性のない3333のようなクレイジーな3番目のパートがあります。