どの「バージョン命名規則」を使用していますか？
異なるバージョンの命名規則は異なるプロジェクトに適していますか？何を使用し、その理由は何ですか？
個人的には、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＃で検索エンジンなどの重要なプロジェクトに取り組んだことがあるこの数回は、この慣習に固執し、内部トラッカーとして効果的に使用できました。
セマンティックバージョニング（ http://semver.org/ ）は、ここで言及する価値があります。これは、[Major].[Minor].[Patch]の形式でのバージョン管理スキームの公開仕様です。このスキームの動機は、バージョン番号と意味を伝えることです。
私はそれを使用しませんが、私は見ました、そしてそれは興味深い構造です：
年。月。日。ビルド
自己説明。
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。 releasesに使用されます。N.x.x、ここでNは整数です。例：1.x.x。 サポートブランチに使用されます。N.M.x、NおよびMは整数です。例：1.0.x。 リリースブランチに使用されます。
これは、バージョン番号付けアプローチの簡単な説明の図です。
PAは pre-alpha を意味しますAは alpha Bは beta ARは alpha-release BRは beta-release RCはリリース候補STは stableを意味します
このようなバージョン番号付けアプローチの利点は次のとおりです。
- アジャイルソフトウェア開発ライフサイクルの詳細を表します。
- ソースコードリポジトリ構造の詳細を考慮します。
- パターンに慣れた人にとっては自己説明です。すべてのパターンは異なるアーティファクトを表しています。このようなパターンは簡単に解析でき、問題追跡などの他の目的に使用できます。
- 説明されているバージョン管理アプローチの基本であるバージョン管理パターンセットは、収集メトリックおよび計画に使用できます。
- 成熟度と品質レベルの概念に焦点を当てています。多くの場合、1.0.0のようなバージョン番号があまり必要なく割り当てられます（ソフトウェアがアルファ版の場合）。提示されたバージョン番号付けアプローチにより、いくつかのレベルの成熟度を確立できます。最も単純なケースでは、2つのレベルしかありません：中間ビルド（
N.x.K）およびrelease（N.M.K）。リリースとは、完全なバージョン番号（N.M.K）は、サプライヤーの会社/組織/チーム内で何らかの品質管理プロセスを経ています。 - これは、開発とテストの両方の俊敏性の証拠です。
- ソフトウェア構造とアーキテクチャへのモジュラーアプローチを推奨します。
より複雑な diagram もあり、バージョン管理のアプローチを詳細に表しています。また、便利な プレゼンテーションスライド バージョン管理アプローチへの移行の説明、および SCMFViz バージョン番号付けアプローチの基本原則を示すアプリケーションを紹介します。プレゼンテーションのスライドでは、ソフトウェアプロジェクトの全期間を通じて同じバージョン管理アプローチを維持することが重要である理由も説明しています。
実際には、実際のバージョン番号の代わりにdate versionを使用することに対する私の態度は、日付のあるバージョンのソフトウェアの開発者が次のことを想定している。
- ソフトウェア開発ライフサイクルについて何も知りません。開発は通常、俊敏で反復的です。バージョン番号付けのアプローチは、ソフトウェア開発プロセスの反復的な性質を表す必要があります。
- ソフトウェアの品質を気にしないでください。品質管理と保証は、俊敏で反復的です。開発と同じように。また、バージョン番号は、開発と品質管理/保証の両方の俊敏性と反復性を示すものでなければなりません。
- アプリケーションのアーキテクチャまたはアイデアは気にしないでください。メジャーバージョン番号（
NinN.M.K）は、アーキテクチャソリューションとアプリケーションの基本原理の両方を担当します。メジャーバージョン番号Nは、アーキテクチャの変更またはその動作/機能の主要なアイデアと原則の変更に応じて変更されます。 - コードベースを制御できません。ブランチ（トランク）はおそらく1つだけで、すべてに使用されます。個人的には、コードベースが1つの大きなガベージダンプになることを奨励するので、私は正しくないと思います。
このアプローチは少し物議を醸すように見えるかもしれませんが、これはソフトウェアに適切なバージョン番号を与える最も簡単な方法だと思います。
リリースするすべてのメジャーバージョンについて、内部でそれを呼び出す作業バージョンがあることは珍しくありません。たとえば、私の最後の仕事では、次のUbuntuにヒントを得た命名規則を使用したメジャーバージョンを参照しました。
[病弱な状態] [別称動物名]
「Limp Lamprey」、「Wounded Wombat」、「Asthmatic Anteater」などの名前が付けられました。
それが本当にクールな名前でない限り、顧客に漏れないことを確認してください。
Generation.Version.Revision.Build（9.99.999.9999）
世代はほとんど変わりません。大きな成果をあげているのは、DOS-> Windows、完全なリエンジニアリングです。
バージョンは、互換性のない大きな変更、新しい機能、ソフトウェアの特定のパラダイムの変更などのためのものです。
多くの場合、改訂が行われます（マイナー機能とバグ修正）。
ビルドは内部情報です。
git describeは、選択した番号付け規則に素敵な拡張を提供します。これをビルド/パッケージング/デプロイメントプロセスに埋め込むのは簡単です。
タグ付きリリースバージョンにA.B.C（major.minor.maintenance）という名前を付けたとします。 git describe特定のコミットで、コミットのタグ付けされた最新の祖先を見つけ、それ以降のコミット数、およびコミットの省略されたSHA1を追加します。
1.2.3-164-g6f10c
もちろん、実際にいずれかのバージョンを使用している場合は、タグ（1.2.3）を取得します。
これには、すべてのビルドに自分で番号を付ける必要がない一方で、どのソースからビルドしたかを正確に知らせる正確にの利点があります。
私は、いくつかの意味的な意味を割り当てるバージョン番号を好みます。バージョン番号を使用して、ソースコード（およびアクティビティ管理システム）で発生した変更に対する特定のバージョンで報告されたバグを追跡できる限り、おそらく正しい方法を使用しています。
私は.NETを使用しているので、.NETバージョンの番号付けシステムに悩まされていますが、番号に意味的な意味を与えようとしています
major.minor.build.revision
- メジャー=（プロジェクトまで）
- マイナー=（プロジェクトまで）
- build = Hudsonからのビルド番号（ここではTeamCityやTeamBuildなどを使用できます）
- revision = SubversionまたはBazaarのリビジョン（プロジェクトとその用途によって異なります）
バージョン番号が何らかの方法で表示されることを常に確認します（通常、コンソールベースのプログラムがコンソールに出力され、ログファイルが表示されます。通常、Webアプリは上部のメニューバーにあります）。
このようにして、クライアントが問題を報告した場合、バージョン番号を使用して、クライアントが最新バージョンを使用しているかどうか、および特定のバージョンで発生した問題の数を追跡できます。
トレーサビリティがすべてです！
Major.Minor.Public（ビルド）[alpha/beta/trial]、たとえば「4.08c（1290）」
- Majorはメジャーバージョン番号（1、2、3 ...）
- マイナーは2桁のマイナーバージョン（01、02、03 ...）です。通常、重要な新機能が追加されると、10桁が増加します。これは、バグ修正のみです。
- Publicはビルドの公開リリース（a、b、c、d、e）であり、マイナーバージョンが公開アップデートとしてリリースされない場合、マイナーバージョンとは異なることがよくあります。
- buildは、コンパイラが追跡する実際のビルド番号です。
- これらの特殊なケースには、TRIAL、ALPHA、BETA X、またはRC Xが追加されています。
Major.Minor.Build＃.YYMMDD [suffix]を使用します。通常、特定の日に1回だけ本番ビルドを実行します（ただし、複数の場合はab/c/dサフィックスを使用します）およびYYMMDDは、ユーザー/顧客/管理にビルドの経過時間を示しますが、6.3.1389はそうではありません。
主要な数は、重要な製品機能（有償）とともに増加します。
マイナー番号は修正/改善（無料アップデート）で増加します。
ビルドは常に増加します。すべてのビルドが出荷されるわけではないので、直線的な進行ではありません。
1.0.0 | 1.0.1 | （public 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（public 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_の間のバージョンを示します）。