どのバージョン番号付けスキームをお勧めしますか？
私の質問は、どのタイプのプロジェクトにどのバージョン命名スキームを使用すべきかということです。
非常に一般的なのはmajor.minor.fixですが、これでも4つの数値になる可能性があります（Firefox 2.0.0.16など）。奇数が開発者バージョンを示し、偶数が安定リリースを示すモデルがあるものもあります。また、-dev3、-rc1、SP2など、あらゆる種類の追加機能を組み合わせることができます。
あるスキームを別のスキームよりも優先する理由が存在し、異なるタイプのプロジェクト（つまり、オープンソースとクローズドソース）で異なるバージョンの命名スキームを使用する必要がありますか？
これには2良い答えがあります（さらに多くの個人的な好み、宗教戦争に関するギズモのコメントを参照）
publicアプリケーションの場合、標準のMajor.Minor.Revision.BuildがIMOで最適に機能します-パブリックユーザーは、自分のプログラムのバージョン、およびある程度、自分のバージョンがどれだけ古いかを簡単に知ることができます。
社内アプリケーションの場合、ユーザーがアプリケーションを要求したことはなく、展開はITによって処理され、ユーザーはヘルプデスクに電話をかけることになります。Year.Month.Day.Buildがより適切に機能することがわかりました多くの状況で。したがって、このバージョン番号をデコードして、パブリックバージョン番号スキームよりも役立つ情報をヘルプデスクに提供できます。
しかし、結局のところ、私は何よりも1つの推奨事項を作成します-一貫性を保つことができるシステムを使用してください。コンパイラを毎回自動的に使用するように設定/スクリプト化できるシステムがある場合は、それを使用してください。
発生する可能性のある最悪の事態は、以前のバージョンと同じバージョン番号のバイナリをリリースすることです-私は最近、自動ネットワークエラーレポート（他の誰かのアプリケーション）を処理していて、Year.Month.Dayという結論に達しました。コアダンプに表示されているバージョン番号をビルドし、アプリケーション自体がリモートで最新でない場合（アプリケーション自体が実際の番号を含むスプラッシュスクリーンを使用した場合-もちろん、バイナリから取得されない場合もあります）。その結果、クラッシュダンプが2年前のバイナリ（バージョン番号が示す）から来ているのか、2か月前のバイナリから来ているのかを知る方法がなく、適切なソースコードを取得する方法がありません（ソース管理もありません！）。 ）
私は セマンティックバージョニング の大ファンです
他の多くの人がコメントしているように、これはX.Y.Z形式を使用し、その理由について十分な理由を示しています。
これが私たちの会社で使用するものです：メジャー .マイナー .パッチバージョン .ビルド番号。
メジャーの変更には、マーケティングへの関与など、完全なリリースサイクルが含まれます。この数は、R＆D以外の部隊によって制御されます（たとえば、私が働いた場所の1つで、マーケティングは次のバージョンが'11'-競合他社に対応するため、当時はバージョン2でした:)）.
マイナーは、製品に新しい機能または大きな動作変更が追加されたときに変更されます。
パッチバージョンパッチが正式にバージョンに追加されるたびに1つずつ増加します。通常、バグ修正のみが含まれます。
ビルドバージョンは、顧客向けの特別なバージョンがリリースされたときに使用されます。通常、その修正は次のパッチまたはマイナーバージョンにロールアップされます（そして、Product Managementは通常、追跡システムでバグを「パッチ3でリリースされる」としてマークします）。
私たちの研究開発部門は1.0.0.0.0.000を使用します：MAJOR.minor.patch.audience.critical_situation.build
お願い、しないでください。
この種の質問は客観的な側面よりも宗教戦争についてです。番号付けスキームなどに対する賛否両論は常にたくさんあります。人々があなたに与えることができる（またはすべき）すべては、彼らが使用したスキームと彼らがそれを選択した理由です。
私の側では、X.Y.Zスキームを使用しています。
- [〜＃〜] x [〜＃〜]後方互換性を導入するパブリックAPIの変更を示します
- [〜＃〜] y [〜＃〜]一部の機能の追加を示します
- [〜＃〜] z [〜＃〜]修正を示します（バグを修正するか、機能に影響を与えずに内部構造を変更するか）
最終的に、公式リリースが完了する前にユーザーからのフィードバックが必要な場合は、「ベータN」サフィックスを使用します。誰も完璧ではなく、常にバグがあるため、「RC」接尾辞はありません;-)
major.minor.milestone.revision-buildスキームが優先されます。ここで、
major：アーキテクチャの大幅な変更または機能の重要な進歩により増加します。minor：小さな変更と、アーキテクチャの変更を必要としない新機能。milestone：コードの安定性と成熟度を示します：- 開発/プレアルファ版の場合は0
- アルファの場合は1
- ベータ版2
- リリース候補（RC）の場合は3
- 最終/製品リリースの場合は4
revision：リリース、パッチ、またはバグ修正番号を示します。build：アプリケーションの特定のビルドまたはバージョンへの一意の参照。ビルド番号は連続した整数で、通常はビルドごとに増分されます。
例：
1.4.2.0-798：ビルド番号1.4によって作成されたバージョン798の最初のベータリリース。1.8.3.4-970：1.8-RC4、ビルド番号970によって作成。1.9.4.0-986：ビルド番号1.9によって作成されたバージョン986の最初の製品リリース。1.9.4.2-990：ビルド番号1.9によって作成されたバージョン990の2回目のバグ修正リリース。
製品リリースでは、バージョン文字列の3桁目に常に4が含まれているため、製品リリースでは数字が削除される場合があります。
私は個人的に、MAJOR.MINOR.BUGFIX-SUFFIXを好みます。開発バージョン（バージョン管理チェックアウト）の場合、SUFFIXはdevですrc1/rc2リリース候補の場合、リリースバージョンのサフィックスはありません。
開発チェックアウトのサフィックスがある場合、おそらくリビジョン番号が付いていても、それらを区別するためにそれらを偶数/奇数にする必要はありません。
ライブラリの場合、バージョン番号は2つのリリース間の互換性のレベルを示し、アップグレードの難しさを示します。
バグ修正リリースでは、バイナリ、ソース、シリアル化の互換性を維持する必要があります。
マイナーリリースはプロジェクトによって意味が異なりますが、通常、ソースの互換性を維持する必要はありません。
メジャーバージョン番号は、3つの形式すべてを壊す可能性があります。
根拠について詳しく書いた here 。
アジャイルソフトウェア開発の実践とSaaSアプリケーションにより、メジャーリリースとマイナーリリースのアイデアはなくなりました。リリースは定期的に非常に頻繁に出てくるため、リリース番号のスキームはこの区別は、私にはもはや役に立ちません。
私の会社では、リリースが開始した年の下2桁の後にその年のリリース番号が続く番号付け方式を使用しています。
したがって、2012年に開始された4番目のリリースは12.4になります。
必要に応じて、その後に「バグ修正」バージョン番号を含めることができますが、理想的には、頻繁にリリースしないので、これらはそれほど必要ではありません-「12.4.2」。
これは非常に単純なスキームであり、以前に使用した他のリリース番号付けスキームの問題はありません。
単に
Major.Minor.Revision.Build
ここで使用していたのはmajor.minor.platform.fixです。
major：このビルドから保存されたファイルが以前のビルドと互換性がなくなった場合、この数を増やします。
例：バージョン3.0.0.0で保存されたファイルは、バージョン2.5.0.0と互換性がありません。
マイナー：新しい機能が追加されたときにこの数を増やします。この機能はユーザーが見る必要があります。開発者にとって隠された機能ではありません。メジャーがインクリメントされると、この数は0にリセットされます。
プラットフォーム：これは、開発に使用するプラットフォームです。
例：1は.netフレームワークバージョン3.5を表します。
fix：この新しいバージョンにバグ修正のみが含まれている場合、この数を増やします。メジャーまたはマイナーが増加すると、この数は0にリセットされます。
クローズバージョンとオープンソースのバージョン番号ポリシーの違いは、メジャーバージョンがリリースの年などを反映する場合がある商業的側面にも由来します。