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

その形式で書かれているのを見たことがありません。私が働いている場所では、フォームMAJOR.MINOR.REVISION.BUILDNUMBERを使用しています。ここで、

• MAJORはメジャーリリースです（通常、UIの多くの新機能や変更、または基盤となるOS）
• MINORは、以前のメジャーリリースのマイナーリリース（おそらくいくつかの新機能）です
• REVISIONは通常、以前のマイナーリリースの修正です（新機能はありません）
• BUILDNUMBERは、リビジョンの最新のビルドごとに増分されます。

たとえば、リビジョンがQA（品質管理）にリリースされ、問題が発生します。変更が必要です。バグは修正され、同じREVISION番号でQAにリリースされますが、BUILDNUMBERが増加します。

コメント

• +1：それ’は、他の場所でも’見たのとほぼ同じです。 ‘一部の企業がBUILDNUMBERにDateTimeスタンプを使用する方法を見て、気に入りました。
• +1：” MAJOR.MINOR.REVISION.BUILDNUMBER “形式は理解しやすく、意味があります。 MSDNサイトでBUILDNUMBER.REVISIONフォーム（問題のリンクが更新されました）を見て、完全に混乱しました。
• 奇妙なことです。改訂が最後であることが最も理にかなっていると思います-‘（おそらく）最も変更される数です。
• @Izkata、実際にはビルド数は最も変化します。少なくとも、医療機器を製造しているため、厳密なバージョン管理を使用する現在の主契約での使用方法です。更新されたリビジョンは、以前のソフトウェアに修正が加えられていることを示しています。これは、QA（品質保証）によるテストが必要です。これは完全に独立した部門であり、3日間の広範なテストを行います（FDAガイドラインによる）。問題が見つかった場合は、新しいビルド（再コンパイルとリンク）と再テストを必要とする追加のコード変更が必要になる可能性がありますが、リビジョン番号は同じままです。
• @tcrosley私はそれを推測します’用語が不明確な場合。バージョン管理の改訂を考えていました。

混乱は、さまざまなセマンティクスは、MSが「ビルド番号」、特に「リビジョン」に使用します。用語は単に異なる意味を持っています。

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

ただし、REVISIONをインクリメントすると、新しいパーマネントリリースブランチが示されます。そのため、BUILDの前に配置します。このアプローチの欠点は、次の一連のイベントが発生する可能性があることです。

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

ご覧のとおり、次の変更に含まれる変更は修正プログラムだけではありません。ビルド、またボブの変更もそのビルドの一部になります。現在のブランチを安定させたい場合、ボブがたくさんのバグを追加したかどうかわからないため、問題が発生する可能性があります。

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

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

REVISIONという用語は

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

2つのプロセスの主な違いは、CIビルドに修正プログラムを適用する機能が必要かどうかです。プロセスのどの時点で分岐が行われます。この側面は、すべてのテストが成功した後いつでも特定のビルドを選択して、そのバージョンを製品の次の公式リリースに正確にプロモートできるようにする場合に重要になります。

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

を参照してください。また

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

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

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

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

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

コメント

• これは素晴らしい答えです！ +1

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

major.minor [.build [.revision]]

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

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

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

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

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

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

コメント

• この標準を誰も知らない理由は私を困惑させます。ここでのすべての回答は、ビルドが最後に行われ、’ tはリビジョンが非常に単純であることを理解しています。修正プログラムを意味します。ビルドをリリースしてからさらにビルドを作成しますが、そのリリースに戻って修正する必要がある場合は、リビジョンを更新して、リリースされた特定のビルドが新しいリリース用に変更されたことを示します
• +1 for正当なビルド番号を持つ回答。リビジョンが同じままである場合（時間に依存する非常識なビルドシステムがない限り）、数を増やすだけではかなり役に立ちません。ビルド番号を使用して、どのコンパイラ、プラットフォームなどが有用であるかを通知します。
• Buildをrecompilation of the same sourceは見逃されている重要なポイントのようです。 ‘コードの変更（’がまったく新しいメジャー/マイナーの増加を必要としない）の場合、Revisionも変更する必要があります。
• @PeterX再ターゲット時のビルド固有の変更の場合と同様ですか？
• “ビルド番号の違いは、同じソースの再コンパイルを表します”はドキュメントと矛盾しているようです。改訂を行うと、同じソースではなくなります。 REVISIONの前にBUILDを使用することは、リビジョンが”プロセッサ、プラットフォーム、またはコンパイラの変更”を表すビルドに固有である場合にのみ意味があります。したがって、これらの説明を使用する場合、REVISIONバンプとして最もよく見られるものは、実際にはマイナーバンプであるはずです。ドキュメントでは、修正プログラムにREVISIONを使用することに言及していますが、修正プログラムはすべてのビルドに適用されると想定しているため、マイナーなバンプになるはずです。論理的な一貫性が欲しいだけです!!

少なくとも2つの異なることができます。参照するビルド番号を想像してみてください：

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

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

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

コメント

• +1 for＃1。私はソースコントロールのリビジョン番号。ソースコントロールでそのバージョンに対して報告されたバグを簡単に検索できるためです。
• @MasonWheeler：SVNを使用している場合はうまく機能します。ただし、dcvsにアクセスすると、リスを取得しますy。これは、私がsvn I ‘で最も見逃していることの1つです。

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

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

ほとんどの継続的インテグレーションエンジンでは、自動生成された一意のビルド番号が許可されています。

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

チーム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に表示されます。

希望これは明確で役立ちます。

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

どのように表示して使用するかを説明します…

プログラム名バージョンmajor.minor.build.revision

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

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

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

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

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

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

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

必要なものは何でもかまいません。あるべきです。私はmajor.minor.build.revisionにyear.month.day.hhmmを使用する傾向があります。私が1分以上生産している場合、何かが間違っています。単純なインクリメントを使用することもできますが、それらに精巧なジェネレーターをいくつか見たことがあります。 何をしたいのか。彼らがする必要があるのは、以前のソースに到達できるようにすることです。その出力を作成するので、それを可能にするものは何でも。

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

jkohlheppと同様に、バージョンの3番目の部分を使用してSubVersionのリビジョン番号を表示し、4番目の部分を使用して継続的インテグレーションサーバー（Jenkinsの場合）からのビルド番号これにより、いくつかの利点が得られます。CIサーバーによってバージョン番号を設定すると、誤って発生する可能性のある手動の手順が削除されます。逃した;開発者が開発用PCから生意気なリリースを行っていないことを確認するのは簡単です（これにより、これらの数値はゼロになります）。また、バージョン番号を確認するだけで、ソフトウェアを 生成されたコードとそれを構築したCIジョブの両方に結び付けることができます。これは、非常に便利な場合があります。

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

1.01.2.1234

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

コメント

• OPは、リビジョンIDのビルド番号ではなく、ビルド番号を尋ねています。