MAJOR.MINOR.BUILDNUMBER.REVISIONのビルド番号は正確には何ですか

ビルド番号について考えると、新しいナイトリービルドが作成されるたびに、新しいビルド番号が生成され、そのビルドに割り当てられます。したがって、7.0バージョンのアプリケーションでは、ナイトリービルドは7.0.1、7.0.2などになります。そうですか？それでは、ビルド番号の後のREVISIONの使用は何ですか？または、毎晩のビルド後に改訂部分が増分されますか？私はここで少し混乱しています...私たちは、各ナイトリービルドを参照してくださいBUILD？

形式はここに記載されています：AssemblyVersion-MSDN

その形式で書かれたのを見たことがない。私が働いている場所では、MAJOR.MINOR.REVISION.BUILDNUMBERという形式を使用しています。ここで、MAJORはメジャーリリース（通常は多くの新機能またはUIまたは基盤となるOSの変更）で、MINORはマイナーリリース（おそらくいくつかの新機能）です以前のメジャーリリースであるREVISIONは、通常、以前のマイナーリリース（新しい機能はありません）の修正であり、BUILDNUMBERはリビジョンの最新ビルドごとに増加します。

たとえば、改訂版がQA（品質管理）にリリースされ、変更が必要な問題が再発する場合があります。バグは修正され、同じ改訂番号でQAにリリースされますが、BUILDNUMBERは増加します。

全体の混乱は、MSが「ビルド番号」、特に「改訂」に使用するさまざまなセマンティクスに起因しています。用語は単に異なることを意味します。

ほとんどの人（私自身も含む）は、何らかの理由で新しいビルドを作成する必要がある場合は常に、より高いBUILD番号を取得するセマンティックバージョン番号付けスキームを使用します。私たちにとって、ホットフィックスは単なるコード変更と見なされ、ビルド部分はCIを実行するたびに自動的に増加します。同じMAJ.MIN.REVを持つモジュールは互換性があると見なされ、BUILDはどちらが最も新しいかを示します。

ただし、REVISIONの増分は、新しい永続リリースブランチを示します。そのため、ビルドの前に配置します。このアプローチの欠点は、次の一連のイベントが発生する可能性があることです。

• コミット番号4711：アリスは機能Aを追加しました
• CIはビルド1.2.3.100を生成します
• コミット番号4712：ボブは機能Bを変更しました
• コミット番号4713：アリスが機能Aを修正（「修正プログラム」）
• CIはビルド1.2.3.101を生成します

ご覧のとおり、次のビルドに含まれる変更はホットフィックスだけではなく、Bobの変更もそのビルドの一部になります。現在のブランチを安定させたい場合、ボブがたくさんのバグを追加したかどうかわからないので、トラブルに遭遇するかもしれません。

MSは両方の用語を異なる方法で使用します。BUILD番号は自動的にインクリメントされません。代わりに、特定のバージョンのコードに使用されるコードをフリーズするためのリリースブランチのようなものと見なすことができます。REVISIONは、そのBUILDブランチに適用される追加の「ホット」変更を示します。したがって、シーケンスは次のようになります。

• コミット番号4711：アリスは機能Aをトランク/マスターに追加しました
• カールがビルドブランチを作成 1.2.100
• CIはビルド1.2.100.0を生成します
• コミット番号4712：ボブはトランク/マスターの機能Bを変更しました
• コミット番号4713：アリスは1.2.100ブランチの機能Aを修正しました
• CIはビルド1.2.100.1を生成します

REVISIONという用語は、

• 製品リビジョン（つまり、ほとんどの人がそれを使用する方法です）
• 特定のデイリービルドのリビジョン（MSが行うこと）

2つのプロセスの主な違いは、CIビルドにホットフィックスを適用するかどうか、したがってプロセスのどの時点でブランチが作成されるかです。この側面は、すべてのテストが成功した後、いつでも特定のビルドを選択し、製品の次の公式リリースに正確にそのバージョンをプロモートできるようにする場合に重要になります。

この場合、CIツールはリポジトリタグを作成するため、必要なときに必要な情報をいつでも使用できます。SVNでは、タグとブランチがまったく同じ方法で実装されるため、さらにシンプルになります。タグはの下にあるブランチにすぎません/tags。

こちらもご覧ください

TFS分岐戦略の FAQセクションから：

どのブランチでP1（ホットフィックス）チケットを修正する必要がありますか？

• P1は、実稼働環境で実行されているコードベースに最も近いブランチで修正する必要があります。この場合、P1はProdブランチで修正する必要があります。他のブランチで修正を適用し、本番環境に変更をロールアウトすると、後続の反復から半完成または未テストのコードがリリースされる危険があります。

• ここで、Prodブランチに対して直接作業することが安全であるかどうかを議論するかもしれませんが、すぐに注意が必要なP1はシステムの根本的な問題ではないはずです。それが根本的な問題である場合は、さらなる分析と顧客との議論が必要になる可能性があるため、製品のバックログに追加する必要があります。

もう1つの良い読み物はTFS分岐ガイドです

Microsoftは、VersionクラスのMSDNドキュメントで.NETバージョン番号の各コンポーネントの目的を説明しています。関連する部分は次のとおりです。

major.minor [.build [.revision]]

コンポーネントは、慣例により次のように使用されます。

メジャー：同じ名前で異なるメジャーバージョンのアセンブリは交換できません。より高いバージョン番号は、下位互換性を想定できない製品の大幅な書き換えを示している場合があります。

マイナー：2つのアセンブリの名前とメジャーバージョン番号が同じで、マイナーバージョン番号が異なる場合、これは下位互換性を目的とした大幅な機能強化を示しています。このマイナーバージョン番号は、製品のポイントリリースまたは製品の完全な下位互換性のある新しいバージョンを示している場合があります。

ビルド：ビルド番号の違いは、同じソースの再コンパイルを表します。プロセッサ、プラットフォーム、またはコンパイラが変更されると、異なるビルド番号が使用される場合があります。

リビジョン：同じ名前、メジャー、およびマイナーバージョン番号を持つアセンブリですが、異なるリビジョンは完全に互換性があります。以前にリリースされたアセンブリのセキュリティホールを修正するビルドでは、より高いリビジョン番号が使用される場合があります。

http://msdn.microsoft.com/en-us/library/system.version.aspx

ビルド番号が参照していると想像できるものが少なくとも2つあります。

1. リリースされたソース管理バージョン。たとえば、リビジョン＃12345のリリースがあった場合、これをビルド番号にすることで追跡でき、メジャーバージョンまたはマイナーバージョンを増やす新しい機能ではないため、リビジョンが上がる可能性のあるパッチを適用した場合誰かがそのビルドを再度実行したい場合に備えて、ビルド番号を覚えておく必要があります。

2. 継続的統合サーバー識別子。この場合、CIサーバーは実行する各ビルドに番号を付けることができるため、ビルド番号は成功したビルドが取得するものであり、このシナリオではリビジョン部分は必要ありません。

私が知らない他の人もいるかもしれませんが、これらはコードベースの数字に関して私が知っている大きなものです。

ビルド番号は通常、ビルドごとにインクリメントされるため、一意です。

簡単にするために、メジャー番号またはマイナー番号がぶつかるたびにビルド番号をリセットする人もいます。

ほとんどの継続的統合エンジンは、自動生成された一意のビルド番号を許可します。

このリビジョンは、ビルドのパッチに使用できます。2つのチームが製品に取り組んでいるとしましょう。

チーム1は主要な開発チームであり、次のバージョンスキーマ1.0.X.0でナイトリービルドを生成します。Xは増分されます。現在、チームはビルド1.0.50.0にあります。チーム2は時々ビルドを行っています。先週のビルド1.0.43.0を使用して、使用を開始したとしましょう。チーム2が1.0.43.0で問題を検出すると、チーム1は1.0.51.0に進みます。

これで、チーム1がそのビルド（43）を取得し、問題を修正して、チーム2にビルド1.0.43.1を提供します。修正はメインビルドにも反映される可能性があるため、変更は1.0.52.0に反映されます。

これが明確で役立つことを願っています。

*プロジェクトに関係する全員が同じビルドを使用しているわけではなく、特定のビルドにパッチを適用する必要がある場合に、リビジョンが役立ちます。

私がそれをどのように見て、どのように使用するかを言ってみましょう。

ProgramNameバージョンmajor.minor.build.revision

major：私にとっては、現在取り組んでいるプロジェクトです。同じプログラム名の新しいプロジェクトを開始するまで、番号は変わりません。これは、文字通り同じ性別の新しいプログラムを作成することを意味します（例：アクセスv1-アクセスv-2-アクセスv-3 *すべて同じプログラムですが、完全に書き換えられます）。

マイナー：これは、現在公開されているプロジェクトに機能を追加していることを意味します。たとえば、領収書を印刷する機能を追加したり、写真をインポートする機能を追加したりできます。基本的に追加機能を追加し、次のメジャーリリースがそれを行うのを待たないようにします。

build：これは、公開されているmajor.minorバージョンの非常に小さな変更を示すために使用します。これは、レイアウト、配色などの変更である可能性があります。

リビジョン：これは、現在公開されているmajor.minor.buildのバグ修正を示すために使用します-現在のプロジェクトが進行しておらず、バグが発生している場合があります。このバグは修正して公開する必要があります。これは、すでに公開したものを修正して適切に機能することを意味します。新しいビルド、新しい追加に取り組んでいる場合、または新しいメジャーバージョンを開始した場合にも、これを使用します。次のメジャーリリース、マイナーリリース、またはビルドリリースを待っている間に、公開バージョンにパッチを適用する必要があることは明らかです。

したがって、この方法で、完成したプロジェクトまたは停止したプロジェクトを修正し、次のリリースが公開されるまで使用可能にすることができます。

これにより、このタイプのバージョニングがどのように機能する（または機能する）かについて、よりよく理解できるようになることを願っています。私にとっては、このタイプのバージョニングを使用するときに、あらゆるタイプの本当の意味をなす唯一の定義と実践です。

リリースIDの最後の番号としてビルド番号を見たことがあります。ビルド番号の改訂をどのように思い付くのかわかりません。ビルドされていないリソース（アイコン、DBスクリプトなど）の一部を変更した場合、おそらく私が最近取り組んできたほとんどのプロジェクトはバージョン管理下にもあるので、ビルドプロセスはそれらを選択しますインストーラー/リリースの作成。@Davidの説明どおりではありませんが、タイムスタンプ付きのビルド番号が好きです（major.minor.revision.HHMMが好きです）。ただし、私が作業する場所では、ビルドサーバーが生成する連続番号を使用します。

jkohlheppと同様に、バージョンの3番目の部分を使用してSubVersionのリビジョン番号を表示し、4番目の部分を継続的統合サーバー（Jenkinsの場合）からのビルド番号を表示します。これにより、いくつかの利点が得られます。CIサーバーで設定されたバージョン番号を使用すると、誤って見逃してしまう可能性のある手動の手順が削除されます。開発者が開発用PCから生意気なリリースを行っていないことを確認するのは簡単です（これらの数値はゼロになります）。そして、それは私たちが戻ってそれから生成されたコードの両方にソフトウェアの任意の部分を結ぶことができますし、私たちは時折、非常に便利-ちょうどバージョン番号を調べることで、それを建てCIジョブ。

あなたが望むものは何でもあります。major.minor.build.revisionにはyear.month.day.hhmmを使用する傾向があります。1分間に1つ以上を生成している場合、何か問題があります。単純な増分を使用するか、それらの精巧なジェネレーターを見ました。何をすべきか、あなたはそれになりたいです。彼らがする必要があるのは、その出力を作成するために使用されるソースに到達するようにすることです。

最後の2桁は合計ビルド番号です

1.01.2.1234

ビルド番号は2.1234ですが、2つの部分は頻繁に変更されないため、ほとんどの人は1234を使用します。

私たちのチームは、Subversionリポジトリのリビジョン番号として3番目の番号（リビジョン）を使用します。実際にビルドを作成するTeamCity継続的統合サーバーからのビルド番号として、4番目の番号（ビルド）を使用します。TeamCityは、ビルドプロセス中に正しい#sを含む新しいAssemblyInfoファイルを作成します。