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