MAJOR.MINOR.BUILDNUMBER.REVISIONのビルド番号は正確には何ですか
ビルド番号について私が考えるのは、新しい夜間ビルドが作成されるたびに、新しいBUILDNUMBERが生成され、そのビルドに割り当てられるということです。したがって、私の7.0バージョンのアプリケーションの場合、ナイトリービルドは7.0.1、7.0.2などになります。そうですか？それでは、ビルド番号の後のREVISIONの使用は何ですか？または、REVISIONの部分は、毎晩のビルド後に増分されますか？ここで少し混乱しています...毎晩のビルドを[〜＃〜]ビルド[〜＃〜]と呼びますか？
形式は次のとおりです： AssemblyVersion-MSDN
私はそれがその形で書かれたのを見たことがありません。私が作業している場所では、MAJOR.MINOR.REVISION.BUILDNUMBERという形式を使用しています。MAJORはメジャーリリース（通常、多くの新機能またはUIまたは基になるOSの変更）で、MINORはマイナーリリース（おそらくいくつかの新機能）です。以前のメジャーリリース、REVISIONは通常、以前のマイナーリリースに対する修正（新しい機能はありません）であり、BUILDNUMBERはリビジョンの最新のビルドごとに増分されます。
たとえば、リビジョンがQA（品質管理）にリリースされ、変更が必要な問題が発生する場合があります。バグは修正され、同じREVISION番号でQAにリリースされますが、BUILDNUMBERが増加します。
全体の混乱は、MSが「ビルド番号」、特に「リビジョン」に使用する異なるセマンティクスに起因します。用語は別の意味です。
ほとんどの人（私も含む）は セマンティックバージョン番号付けスキーム を使用します。ここで、何らかの理由で新しいビルドを作成する必要がある場合は、より大きなビルド番号を取得します。私たちにとって、修正プログラムは単なるコード変更と見なされ、ビルド部分はCIが実行されるたびに自動的に増加します。同じMAJ.MIN.REVのモジュールは交換可能と見なされ、BUILDは最新のモジュールを通知します。
ただし、REVISIONを増分すると、新しい永続的なリリースブランチが示されるため、ビルドの前に配置します。このアプローチの欠点は、次の一連のイベントが発生する可能性があることです。
- コミット番号4711：アリスが機能Aを追加
- CIはビルド1.2.3.100を生成します
- コミット番号4712：ボブが機能Bを変更
- コミット番号4713：Aliceの修正機能A（「修正プログラム」）
- CIはビルド1.2.3.101を生成します
ご覧のとおり、次のビルドに含まれる変更は修正プログラムだけではありません。ボブの変更もそのビルドの一部になります。現在のブランチを安定させたい場合は、ボブがたくさんのバグを追加しただけかどうかわからないため、問題が発生する可能性があります。
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という用語は、
- a product revision (that's how most people use it)
- 特定のdaily buildのリビジョン（MSが行うこと）
2つのプロセスの主な違いは、CIビルドにホットフィックスを適用する機能が必要かどうか、つまり、プロセスのどの時点でブランチが作成されるかです。この側面は、すべてのテストが成功した後、いつでも特定のビルドを選択し、そのバージョンを製品の次の公式リリースに正確にプロモートできるようにする場合に重要になります。
私たちの場合、CIツールはリポジトリタグを作成するので、必要なときにいつでも必要な情報をすぐに使用できます。 SVNを使用すると、タグとブランチがまったく同じ方法で実装されるため、タグが/tagsの下にあるブランチに過ぎないため、さらにシンプルになります。
こちらもご覧ください
FAQのセクション TFS分岐戦略 から：
P1（修正プログラム）チケットをどのブランチで修正すればよいですか？
P1は、本番環境で実行されているコードベースに最も近いブランチで修正する必要があります。この場合、P1はProdブランチで修正する必要があります。他のブランチで修正を適用し、変更を本番環境にロールアウトすると、後続の反復から半完成またはテストされていないコードがリリースされるリスクがあります。
ここで、Prodブランチに対して直接作業することが安全であるかどうかを論じることができます。もう一度考えてみてください。即時の対応が必要なP1は、システムの根本的な問題ではないはずです。それが根本的な問題である場合は、顧客とのさらなる分析と議論が必要になる可能性があるため、製品バックログに追加する必要があります。
もう1つの読み物は TFS分岐ガイド です。
Microsoftは、VersionクラスのMSDNドキュメントで.NETバージョン番号の各コンポーネントの目的を説明しています。関連する部分は次のとおりです。
major.minor [.build [.revision]]
コンポーネントは、慣例により次のように使用されます。
メジャー：名前が同じでメジャーバージョンが異なるアセンブリは互換性がありません。より高いバージョン番号は、下位互換性を想定できない製品の大幅な書き換えを示している可能性があります。
マイナー：2つのアセンブリの名前とメジャーバージョン番号は同じで、マイナーバージョン番号が異なる場合、これは下位互換性を目的とした大幅な機能強化を示しています。この高いマイナーバージョン番号は、製品のポイントリリースまたは完全に下位互換性のある製品の新しいバージョンを示している可能性があります。
ビルド：ビルド番号の違いは、同じソースの再コンパイルを表します。プロセッサー、プラットフォーム、またはコンパイラーが変更されると、異なるビルド番号が使用される可能性があります。
リビジョン：名前、メジャー、マイナーのバージョン番号が同じで、リビジョンが異なるアセンブリは、完全に交換できるようになっています。以前にリリースされたアセンブリのセキュリティホールを修正するビルドでは、より高いリビジョン番号が使用される場合があります。
ビルド番号の参照で想像できることは少なくともいくつかあります。
リリースされたソース管理バージョン。たとえば、リビジョン＃12345のリリースがあった場合、これはビルド番号にすることで追跡でき、パッチが適用されている場合、メジャーまたはマイナーバージョンを増加させる新しい機能ではないため、リビジョンが上がる可能性があります。誰かがそのビルドを再度実行したい場合に備えて、ビルド番号を覚えておく必要があります。
継続的インテグレーションサーバー識別子。この場合、CIサーバーは実行する各ビルドに番号を付けることができるため、ビルド番号は成功したビルドが取得するものであり、このシナリオではリビジョン部分は必要ありません。
私が知らない他の人がいるかもしれませんが、これらはコードベースの数値に関して私が知っている大きなものです。
ビルド番号は通常、ビルドごとに増分されるため、一意になります。
簡単にするために、メジャー番号またはマイナー番号がぶつかったときにビルド番号をリセットする人もいます。
ほとんどの継続的インテグレーションエンジンでは、自動生成された一意のビルド番号を使用できます。
リビジョンはビルドのパッチに使用できます。 2つのチームが1つの製品に取り組んでいるとしましょう。
チーム1は主要な開発チームであり、Xが増分される次のバージョンスキーマ1.0.X.0でナイトリービルドを生成します。現在、彼らはビルド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
メジャー：私にとっては、現在取り組んでいるプロジェクトです。同じプログラム名の新しいプロジェクトを開始するまで、番号は変わりません。これは、文字通り同じ性別の新しいプログラムを作成することを意味します（例：アクセスv1-アクセスv-2-アクセスv-3 *すべて同じプログラムですが、完全に書き直されます）。
マイナー：これは、現在公開されているプロジェクトに機能を追加することを意味します。たとえば、レシートを印刷する機能や画像をインポートする機能を追加した可能性があります。基本的に、今追加したい追加の機能で、次のメジャーリリースが完了するのを待たないでください。
ビルド：これは、公開されたmajor.minorバージョンの非常に小さな変更を示すために使用します。これは、レイアウト、配色などの変更である可能性があります。
リビジョン：これは、現在公開されているmajor.minor.buildのバグ修正を示すために使用します-現在のプロジェクトが進行しておらず、バグが発生する場合があります。このバグは修正して公開する必要があります。これは、既に公開したものを適切に機能するように修正していることを意味します。新しいビルド、新しい追加、または新しいメジャーバージョンを開始する場合にも、これを使用します。公開されたバージョンは、次のメジャー、マイナー、またはビルドのリリースを待つ間、明らかにパッチを適用する必要があります。
したがって、このようにして、次のリリースが公開されるまで、完成または停止したプロジェクトを修正して使用可能にすることができます。
これにより、このタイプのバージョン管理がどのように機能する（または機能する）かを理解していただけると幸いです。私にとっては、このタイプのバージョン管理を使用するときに、あらゆるタイプの本当の意味をなす唯一の定義と実践です。
私は、リリースIDの最後の番号としてビルド番号を見たことがあるだけです。ビルド番号の改訂をどのように思いつくかわかりません。おそらく、ビルドされていないリソース（アイコン、DBスクリプトなど）のいくつかを変更したと思いますが、最近取り組んだほとんどのプロジェクトでは、これらすべてがバージョン管理されているので、ビルドプロセスがそれらをピックアップします。インストーラー/リリースの作成。 @Davidが説明しているほどではありませんが、タイムスタンプ付きのビルド番号が好きです（major.minor.revision.HHMMが好きです）。ただし、私が作業する場所では、ビルドサーバーが生成する連番を使用します。
Jkohlheppと同様に、バージョンの3番目の部分を使用してSubversionのリビジョン番号を表示し、4番目の部分を使用して継続的インテグレーションサーバー（Jenkinsの場合）からのビルド番号を表示します。これにはいくつかの利点があります。CIサーバーによってバージョン番号が設定されると、誤って見落とされる可能性がある手動の手順が削除されます。開発者が開発用PCから生意気なリリースを行っていないことを確認するのは簡単です（これらの数値がゼロになることになります）。また、バージョン番号を確認するだけで、ソフトウェアを生成したコードの両方に結び付けることができますandバージョン番号を確認するだけで、CIジョブは時々非常に便利です。
それはあなたがそれがなりたいものです。 major.minor.build.revisionにyear.month.day.hhmmを使用する傾向があります。毎分1つ以上生産している場合、何かがおかしい。単純な増分を使用することもできますが、それらのためにいくつかの精巧なジェネレータを見てきました。 あなたになりたい。彼らがする必要があるのは、あなたがその出力を作成するために使用されるソースに到達するようにすることです。
下2桁は総ビルド番号です
1.01.2.1234
ビルド番号は2.1234ですが、2つの部分は頻繁に変更されないため、ほとんどの人は1234を使用します。
私たちのチームは、Subversionリポジトリのリビジョン番号として3番目の番号（リビジョン）を使用します。 4番目の番号（ビルド）は、実際にビルドを作成するTeamCity継続的インテグレーションサーバーからのビルド番号として使用します。 TeamCityは、ビルドプロセス中に、正しい#sを含む新しいAssemblyInfoファイルを作成します。