どのようなバージョン番号付けスキームをお勧めしますか?

StackOverflow https://stackoverflow.com/questions/121795

質問

私の質問は、どのタイプのプロジェクトにどのバージョン命名スキームを使用すべきかということです。

非常に一般的なのは、major.minor.fix ですが、これでも 4 つの数字になる可能性があります (つまり、Firefox 2.0.0.16)。奇数の数字が開発者バージョンを示し、偶数の数字が安定版リリースを示すモデルもあります。また、-dev3、-rc1、SP2 など、あらゆる種類の追加をミックスに含めることができます。

あるスキームを別のスキームより優先し、異なるタイプのプロジェクトを実行する必要がある理由が存在します（つまり、オープンソース vs.クローズド ソース) には異なるバージョン命名スキームがありますか?

役に立ちましたか？

解決

がある 二 これに対する良い答えです (さらに個人的な好みもたくさんあります。宗教戦争に関する gizmo のコメントを参照してください)

のために 公共 アプリケーションでは、標準の Major.Minor.Revision.Build が IMO で最もよく機能します。一般のユーザーは、自分が所有しているプログラムのバージョンと、そのバージョンがどの程度古いかを簡単に知ることができます。

のために 家の中で ユーザーがアプリケーションを要求することはなく、展開は IT 部門が処理し、ユーザーはヘルプ デスクに電話することになるアプリケーションでは、多くの状況で Year.Month.Day.Build がより適切に機能することがわかりました。したがって、このバージョン番号をデコードして、公開バージョン番号スキームよりも役立つ情報をヘルプ デスクに提供できます。

しかし、結局のところ、何よりもお勧めしたいことが 1 つあります。 一貫性を維持できるシステムを使用する. 。コンパイラーが毎回自動的に使用するようにセットアップ/スクリプトを作成できるシステムがある場合は、 それを使って.

起こり得る最悪の事態は、以前のバージョンと同じバージョン番号を持つバイナリをリリースすることです。私は最近、自動ネットワーク エラー レポート (他人のアプリケーション) に取り組んでおり、年、月、日が重要であるという結論に達しました。コア ダンプに表示されるビルド バージョン番号は、アプリケーション自体とまったく最新ではありません (アプリケーション自体は、実際の番号を含むスプラッシュ スクリーンを使用していました。もちろん、想像されるようにバイナリから取得されたものではありません)。その結果、クラッシュ ダンプが 2 年前のバイナリ (バージョン番号が示すもの) から来ているのか、2 か月前のバイナリから来ているのかを知る方法がありません。したがって、正しいソース コードを取得する方法もありません (ソース管理もありません!)。 ）

他のヒント

当社で使用しているものは次のとおりです。 選考科目.マイナー.パッチバージョン.ビルド番号 .

の 選考科目 変更には、マーケティングの関与などを含むリリース サイクル全体が含まれます。この数字は研究開発外部の力によって管理されています (たとえば、私が働いていた職場の 1 つでは、マーケティング部門が競合他社に合わせて次のバージョンを「11」にすると決定しました)。当時はバージョン 2 でした :))。

マイナー 新しい機能や大きな動作の変更が製品に追加されると、変更されます。

パッチバージョン パッチが正式にバージョンに追加されるたびに、通常はバグ修正のみが含まれます。

ビルドバージョン 特別なバージョンが顧客向けにリリースされるときに使用され、通常はその顧客に固有のバグ修正が含まれます。通常、その修正は次のパッチまたはマイナー バージョンにロールアップされます (また、製品管理では通常、追跡システムでバグを「パッチ 3 でリリースされる予定」としてマークします)。

私は大ファンです セマンティック バージョニング

他の多くの人がコメントしているように、これは X.Y.Z 形式を使用しており、その理由については十分な理由があります。

当社の研究開発部門は 1.0.0.0.0.000 を使用しています。MAJOR.minor.patch.audience.critical_situation.build

お願いします、 お願いします, 、そんなことはしないでください。

この種の質問は、客観的な側面よりも宗教戦争に関するものです。番号付けスキームや別の番号付けスキームには、常に多くの賛否両論があります。人々があなたに提供できる（または提供すべき）のは、彼らが使用したスキームと、それを選択した理由だけです。

私の側では、X.Y.Z スキームを使用し、すべてが数値になります。

  • バツ 下位非互換性をもたらすパブリック API の変更を示します。
  • Y いくつかの機能の追加を示します
  • Z 修正を示します (バグの修正、機能に影響を与えずに内部構造を変更する)

最終的に、正式リリースが完了する前にユーザーからのフィードバックが必要な場合は、接尾辞「Beta N」を使用します。完璧な人は誰もいないし、バグは常に存在するので、「RC」という接尾辞は付けません ;-)

個人的には、SUFFIX が MAJOR.MINOR.BUGFIX-SUFFIX の方が好きです。 dev 開発バージョンの場合 (バージョン管理チェックアウト)、 rc1 / rc2 リリース候補の場合は接尾辞なし、リリース バージョンの場合は接尾辞なし。

開発チェックアウトのサフィックスがある場合は、たとえリビジョン番号であっても、それらを区別するためにそれらを偶数/奇数にする必要はありません。

私たちは好みます 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:バージョンの 2 番目のバグ修正リリース 1.9, 、ビルド番号によって作成されました 990.

製品リリースには常に 4 バージョン文字列の 3 桁目は、実稼働リリースでは削除される場合があります。

ライブラリの場合、バージョン番号によって、 互換性のレベル 2 つのリリース間でのアップグレードの難しさ。

バグ修正リリースでは、バイナリ、ソース、およびシリアル化の互換性を維持する必要があります。

マイナー リリースはプロジェクトごとに異なる意味を持ちますが、通常はソースの互換性を維持する必要はありません。

メジャー バージョン番号は 3 つの形式すべてを壊す可能性があります。

根拠について詳しく書きました ここ.

アジャイル ソフトウェア開発の実践と SaaS アプリケーションでは、メジャー vs.マイナー リリースは廃止されました。リリースは定期的に非常に頻繁にリリースされます。そのため、この区別に依存するリリース番号付けスキームは、私にとっては役に立ちません。

私の会社では、リリースが開始された年の最後の 2 桁の後にその年のリリース番号を付ける番号付けスキームを使用しています。

したがって、2012 年に開始された 4 番目のリリースは 12.4 になります。

必要に応じて、その後に「バグ修正」バージョン番号を含めることができますが、理想的には、これらが必要になることがほとんどないほど頻繁にリリースするため、「12.4.2」になります。

これは非常に単純なスキームであり、これまでに使用した他のリリース番号付けスキームの問題はまったく発生しませんでした。

クローズ ソースとオープンソースのバージョン番号ポリシーの違いは、 商業的な側面, たとえば、メジャー バージョンがリリース年を反映できる場合。

私たちがここでやっていたのは、 メジャー.マイナー.プラットフォーム.修正.

選考科目:このビルドで保存されたファイルが以前のビルドと互換性がなくなった場合、この数値を増やします。
例:バージョン 3.0.0.0 で保存されたファイルは、バージョン 2.5.0.0 と互換性がありません。

マイナー:新しい機能が追加されると、この数値が増加します。この機能はユーザーに見てもらう必要があります。開発者向けの隠し機能ではありません。この数値は、メジャーが増加すると 0 にリセットされます。

プラットホーム:これは私たちが開発に使用するプラットフォームです。
例:1 は .net Framework バージョン 3.5 を表します。

修理 :この新しいバージョンにバグ修正のみが含まれる場合は、この数値を増やします。メジャーまたはマイナーが増加すると、この番号は 0 にリセットされます。

単に

Major.Minor.Revision.Build
ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top