異なるバージョンの命名規則は異なるプロジェクトに適していますか？何を使用し、その理由は？
個人的には、16進数のビルド番号（11BCFなど）を好みます。これは非常に定期的に増やす必要があります。そして、顧客向けにシンプルな3桁のバージョン番号、つまり1.1.3。
1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.
回答:
Jeff Atwoodに完全に同意することはめったにありませんが、バージョン番号の.NET規則に関する彼の意見に従う傾向があります。
（メジャーバージョン）。（マイナーバージョン）。（リビジョン番号）。（ビルド番号）
たいていの場合、個人的なプロジェクトでは、これはやり過ぎだと思います。C＃で検索エンジンなどの重要なプロジェクトに取り組んできた数回は、この規則に固執し、内部トラッカーとして効果的に使用することができました。
$version = New-Object System.Version 1, 2, 3, 4; $version.ToString(); $version.Build;
セマンティックバージョニング（http://semver.org/）はここで言及するに値します。これは、バージョン管理スキームのパブリック仕様であり、の形式です[Major].[Minor].[Patch]。このスキームの動機は、バージョン番号と意味を伝えることです。
私はそれを使用しませんが、私は見たことがあり、それは興味深い構造です：
Year.Month.Day.Build
自己説明した。
RubyGems Rationalバージョン管理ポリシーを使用しようとしています。
バージョン番号付けの非常にきめ細かいアプローチを次に示します。
N.x.K、ここでNおよびKは整数です。例：1.x.0、5.x.1、10.x.33。中間ビルドに使用されます。N.M.K、ここNでMおよびKは整数です。例：1.0.0、5.3.1、10.22.33。リリースに使用されます。N.x.x、Nは整数です。例：1.x.x。サポートブランチに使用されます。N.M.x、ここでNおよびMは整数です。例：1.0.x。リリースブランチに使用されます。バージョン番号付けのアプローチを簡単に説明する図を次に示します。
PA意味プレアルファは
A 意味アルファ
B 意味ベータは
AR意味アルファリリースは
BR意味ベータリリースでは、
RC意味のリリース候補を
ST意味し、安定
このようなバージョン番号付けアプローチの利点は次のとおりです。
N.x.K）とリリース（N.M.K）の2つのレベルしかありません。リリースとは、完全なバージョン番号（N.M.K）のソフトウェアが、サプライヤ企業/組織/チーム内で何らかの品質管理プロセスを経たことを意味します。バージョン管理のアプローチを詳細に表す、より複雑な図もあります。また、バージョニングアプローチへの移行を説明する便利なプレゼンテーションスライドと、バージョン番号付けアプローチの基本原則を示すSCMFVizアプリケーションがあります。プレゼンテーションのスライドでは、ソフトウェアプロジェクトの全期間を通じて同じバージョン管理アプローチに従うことが重要である理由も説明しています。
個人的に、実際のバージョン番号の代わりに日付バージョンを使用するという私の姿勢は、日付バージョンのソフトウェアの開発者が以下を前提としている：
NではN.M.K）アプリケーションの両方のアーキテクチャ上のソリューションと基本原理を担当しています。メジャーバージョン番号Nは、アーキテクチャの変更、または主要なアイデアとその動作/機能の原則の変更に応じて変更する必要があります。このアプローチは少し議論の余地があるように見えるかもしれませんが、これはソフトウェアに適切なバージョン番号を与える最も簡単な方法であると信じています。
リリースするメジャーバージョンごとに、内部で呼び出すバージョンを使用することは珍しくありません。たとえば、最後の仕事で、次のUbuntuにヒントを得た命名規則を持つメジャーバージョンを参照しました。
[病状] [動物の名前]
これは、「リンプランプレイ」、「傷ついたウォンバット」、「喘息のアリクイ」などの名前を付けました。
本当にクールな名前でない限り、顧客に漏れないようにしてください。
git describeあなたが選んだ番号付け規則に素晴らしい拡張を提供します。これをビルド/パッケージング/展開プロセスに組み込むのは簡単です。
タグ付きリリースバージョンにABC（major.minor.maintenance）という名前を付けたとします。git describe特定のコミットで、最新のタグ付けされたコミットの祖先を見つけ、それ以降のコミットの数、およびコミットの短縮されたSHA1を追跡します。
1.2.3-164-g6f10c
もちろん、実際にいずれかのバージョンを使用している場合は、タグ（1.2.3）を取得するだけです。
これには、ビルドのソースを正確に知らせることができるというメリットがありますが、ビルドごとに番号を付ける必要はありません。
Major.Minor.Public（ビルド）[アルファ/ベータ/トライアル]（「4.08c（1290）」など）
意味的な意味を割り当てるバージョン番号が好きです。バージョン番号を使用して、ソースコード（およびアクティビティ管理システム）で発生した変更に対する特定のバージョンで報告されたバグを追跡できる限り、おそらく正しい方法を使用しています。
私は.NETを使用しているため、.NETバージョン番号付けシステムにこだわっていますが、数字に意味的な意味を与えようとしています。
major.minor.build.revision
バージョン番号が何らかの方法で表示されることを常に確認します（通常、バッチコンソールベースのプログラムはコンソールとログファイルに印刷され、Webアプリは通常上部のメニューバーに表示されます）
このように、クライアントが問題を報告した場合、バージョン番号を使用して、最新バージョンを使用しているか、特定のバージョンで発生した問題の数を追跡できます。
トレーサビリティがすべてです！
Major.Minor.Build＃.YYMMDD [suffix] を使用します。通常、特定の日に1つの実動ビルドのみを行い（ただし、複数ある場合はab / c / dサフィックスを使用します）、YYMMDDはユーザー/顧客/管理を提供します6.3.1389がそうではないビルドの年齢の指標。
メジャー番号は、重要な製品機能（有料）とともに増加します。
修正/改善に伴い、マイナー番号が増加します（無料アップデート）。
ビルドは常に増加します。すべてのビルドが出荷されるわけではないので、直線的な進行ではありません。
バージョン番号には、競合を回避し、間違ったリリースタイプの問題のバグを修正するのに十分な情報が含まれている必要がありますが、関係のない追加情報を伝えてはなりません。
たとえば、日付を使用すると、顧客は古いバージョンを使用していることがわかり、古いバージョンに対するパッチはわかりにくいバージョンを使用する可能性があります。
私は個人的にセマンティックバージョニングが好きです：
Majorです。Minor。PatchPatch ビルドをリリースするたびに増加します。Minor 後方互換性のある機能が追加されるたびに増加します。Major 新しい機能に後方互換性がない場合に増加します。Major== 0あなたは、アルファ/プレリリースにしています。Major> = 1は公開リリースです。
1.5.3->1.5.4（バグ修正）->1.6.0（マイナー機能）->2.0.0（重大な変更）
1.5.3を使用している場合1.5.4、パッチを取得するためにアップグレードできる1.6.0こと、機能を追加すること、およびアップグレードするべきではないことを一目で知ることができます2.0.0（少なくとも変更を処理せずに）。
1.0.0
|
1.0.1
|
（パブリック1.0）1.0.2 -----
| \
2.0.0 1.1.0
| |
2.0.1 1.1.1（パブリック1.1）
|
（パブリック2.0）2.0.2 -----
| \
3.0.0 2.1.0
|
2.1.1（パブリック2.1）
|
2.2.0
|
2.2.1
X.Y.Z内部バージョン番号です。X.Yは公開バージョン番号で、クライアントにとって意味のあるものです。ときX.Y.Zバージョンはパブリックになり、そこになることはありませんX.Y.(Z+1)バージョン：公共のバージョンは、常にセリエの最後です。
X メジャーバージョンがリリースされると増分されます。
Y これらのメジャーリリースのメンテナンスブランチに使用され、バグ修正のみに使用されます。
Z内部で使用され、固定の意味はありません。これまでZ、アプリケーションに非開発者向けに興味深い機能セットがあり、比較的安定していると思うと、新しいバージョンを作成します。このようにして、誰かが尋ねたときに、アプリケーションの「最後の既知の良いバージョン」のデモを表示できます。近い将来、Zバグトラッカーで機能の「ターゲット」の命名に番号バージョンを使用する予定です。
補足としてrelease、バージョン番号をインクリメントするために（コマンドと共に）mavenを使用します。だから、そこにあるX.Y.Z-SNAPSHOT、あまりにも（間のいずれかのバージョンを示しているバージョンX.Y.(Z-1)とX.Y.Z）。