ソフトウェアバージョンの命名規則とステージ指示

序文

多くの開発者は、基本的には、反復の一つまたは二つのバージョンを通過するまで行われ、プロジェクトは基本的に別のグループに転送されますか、常にそのようなことの後に残して、継続的な製品反復プロセスを経験していません業界を去るまで繰り返します。

開発者3ヶ月ものこのバージョンを修正し、バグがある場合はアップグレードする方法、バージョン1を配置、バージョンを開発するには？VERSION2かもしれバグがある場合は、このバグ修正の後に、これは、いない製品ラインに続く場合、このバージョンあなたは素晴らしいものだ。VERSION3続ける場合があります、そしてどのような機能のバージョンを覚えておくことは困難です。将来の製品のラインは、だけでなく、アップグレードする場合は、これを続けた後、それはversion9999に達する可能性があり、想像することができます...

命名フォーマット

バージョン管理の3種類より多くの共通の命名形式：GNUスタイルのバージョン番号の命名形式、Windowsスタイルのバージョン番号の命名形式は、.NET Frameworkのスタイルのバージョン番号は、命名形式。

GNUスタイルのバージョン番号の命名形式

主副バージョン番号のバージョン番号[リビジョン番号[ビルド番号]]
Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]
例：1.2.1, 2.0, 5.0.0 build-13124

Windowsスタイルのバージョン番号の命名形式

主副バージョン番号のバージョン番号[リビジョン番号[ビルド番号]]
Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]]
例：1.21, 2.0

.NET Frameworkのスタイルのバージョン番号の命名形式

。プロモーターメジャーバージョン番号バージョン番号[コンパイルされたバージョン番号[リビジョン番号]。]
Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]
2〜4の部分のバージョン番号：メジャーバージョン、マイナーバージョン番号、ビルド番号とリビジョン番号。メジャーバージョン番号とマイナーバージョン番号が必須であり、内部バージョン番号とリビジョン番号はオプションですが、リビジョン番号の一部を定義した場合、ビルド番号は必須です。定義のすべての部分は、より整数大きいこと、または0に等しくなければなりません。

これらの部品は、次の規則に従って使用する必要があります。

Major：プログラムと同じ名前が、メインアセンブリの異なるバージョン番号と互換性がありません。例えば、これは、それが不可能な下位互換性を書き換えできるようになり、製品の書き換えの多くに適用されます。

Minor：2つのアセンブリの場合と同じ名前のメジャーバージョン番号、大幅に強化示し、異なるバージョンの第二の数、しばらくが、下位互換性の世話をします。例えば、これは、製品のリビジョンまたは完全な下位互換性の新しいバージョンに適用されます。

Build：別のビルド番号がなされ、同じソースの再コンパイルを表します。これは、状況はプロセッサ・プラットフォームやコンパイラを変更するために適しています。

Revision名前は、メジャーバージョン番号とマイナーバージョン番号は同じですが、異なるアセンブリのリビジョン番号は完全互換でなければなりません。これは、以前にリリースされたアセンブリの修理セキュリティの脆弱性に適用されます。

フォローアップアセンブリのみ内部バージョン番号のバージョンまたは異なるリビジョン番号はパッチの以前のバージョン（修正）更新であると考えられます。

市場での現在のソフトウェアは基本的にので、ここでの終了を移動しているので、私たちはGNUスタイルをご紹介します。

ソフトウェアのバージョンフェーズ説明

ベースバージョン：このバージョンでは、ソフトウェアは、通常はすべての機能とページレイアウトが含まれていますが、ページは、単にサイトのインフラ全体として、完全な実装を機能していないだけで、偽のページへのリンクであることを示しています。
アルファ版：この段階では、このバージョンのソフトウェアのみ通常、一般的には、ソフトウェアのより多くのバグバージョンを、社内のソフトウェア開発者を交換し、主な機能は、ソフトウェアベースで実装されていることを示し、我々は変更を継続する必要があります。
ベータ版：αバージョンにこのバージョンの相対は大幅に重大なミスを排除し、改善されているが、まだいくつかの欠陥、さらに排除するためにいくつかのテストを通過する必要があり、そのようなソフトウェアのこのバージョンでの主な変更点はありますUI 。
RC版：このバージョンはすでにかなり成熟しているが、基本的にはバグは、エラーが存在しない原因とほぼ同じの次期リリースの公式バージョン。
リリースバージョン：このバージョンの手段「最終版」、ベータ以前のバージョンの一連の後には、すべての後に、正式なバージョンがあるでしょう、それはユーザーの最終版を提供することです。このバージョンはまた時々標準バージョンと呼ばれています。通常の状況下では、リリース・ワードは、記号（R）に置き換えられ、カバー上のソフトウェアの形で表示されません。

バージョンの命名規則

ソフトウェアのバージョン番号は4つの部分から成ります。

最初の部分は、メジャーバージョン番号です
第二部は、マイナーバージョン番号です
第3の部分はステージのバージョン番号であります
第四の部分は、バージョン番号の日は、ギリシャ語のアルファベットのバージョン番号をインクリメントされています

バージョン番号の変更ルール

主版本号修改機能は、全体的な構造内のモジュールまたは変更の数を増加させるように、より大きな変化を有する場合。このバージョン番号は、プロジェクトが変更されるか否かによって決定されます。
子版本号修改増加または特定の機能変更、このようなアクセス制御の増加など、その他の機能は、カスタムビューを追加した場合。このバージョン番号は、プロジェクトが変更されるか否かによって決定されます。
阶段版本号修改バグフィックス一般的にまたはいくつかの小さな変更が、あなたは常に改訂版を公開するための重大なバグを修正、改訂版、限られた時間間隔を公開する必要があります。このバージョン番号は変更するかどうかのプロジェクトマネージャーによって決定されます。
日期版本号変更されたプロジェクトのための現在のレコードの日付は、変更されたプロジェクトの毎日は、バージョン番号の日付を変更する必要があります。このバージョン番号は、開発者が修正するかどうかによって決定されます。
希腊字母版本号開発段階にあるソフトウェアの現在のバージョンにラベルを付けるために使用されるこのバージョン番号は、我々は別のステージには、このバージョンのソフトウェアを変更する必要があります。このバージョン番号は、プロジェクトが変更されるか否かによって決定されます。

マイルストーンのバージョン番号

芸名	相の同定
コントロールを要求	A
設計フェーズ	B
コーディング段階	C
ユニットテスト	D
ユニットテストの変更	E
統合テスト	F
統合テストの変更	グラム
システムテスト	時間
修正システムテスト	私
受け入れテスト	J
受け入れテストの修正	K