web-dev-qa-db-ja.com

使用するバージョン番号付けスキームは何ですか？

変更の程度、特に互換性を表すバージョン番号付けスキームを探しています。

Apache APR たとえば、よく知られているバージョン番号付けスキームを使用します

<major>.<minor>.<patch>
example: 4.5.11

Mavenは、同様ですがより詳細なスキーマを提案しています。

<major>.<minor>.<patch>-<qualifier>-<build number>
example: 4.5.11-RC1-3732

Mavenのバージョン管理スキームはどこで定義されていますか？修飾子とビルド番号の規則はありますか？おそらく、Mavenを使用するのは悪い考えですが、Mavenバージョンスキームに従わないでください...

他にどのようなバージョン番号付けスキームを知っていますか？どのスキームを好みますか、またその理由は何ですか？

schemaversioningmaven
27
deamon

これが 現在のMavenバージョン比較アルゴリズム と ディスカッション です。バージョンが大きくなるだけで、ビルド番号を除くすべてのフィールドが手動で更新される限り、問題ありません。修飾子は次のように機能します。一方が他方のプレフィックスである場合、長い方が古いです。それ以外の場合は、アルファベット順に比較されます。プレリリースに使用します。

互換性を表現するためのセマンティックバージョニングの使用を支持する。メジャーは下位互換性のない変更用、マイナーは下位互換性のある機能用、パッチは下位互換性のあるバグ修正用です。ライブラリユーザーがライブラリへの依存関係を正しく表現できるように、それを文書化します。スナップショットは自動化されており、プレフィックスの比較方法のため、リリース後の最初のスナップショットを除いて、これらをインクリメントする必要はありません。

25
Tobu

Mavenバージョン管理システムも準拠しているように見えるセマンティックバージョニング標準をお勧めします。チェックしてください、

http://semver.org/

要するにそれは<major>.<minor>.<patch><anything_else>、そしてあなたはあなたに合うと思われる他の部分に追加のルールを追加することができます。例えば。 -<qualifier>-<build_number>。

23
sixohsix

完全を期すために、 old Appleバージョン番号の標準 。これはメジャーバージョンのようになります。マイナーバージョン。バグバージョン。ステージ。非リリースリビジョン。ステージはセットから引き出されたコードですd =（開発）、a（アルファ）、b（ベータ）、またはfc（最終的な顧客の出荷-リリースとほぼ同じ候補者、私は思う）。

ステージおよび非リリースリビジョンは、適切なリリースがないバージョンでのみ使用されます。

したがって、何かの最初のバージョンは1.0.0である可能性があります。バグ修正を1.0.1として、新しいバージョン（より多くの機能を含む）を1.1として、書き直しまたはメジャーアップグレードを2.0としてリリースした可能性があります。その後、2.0.1に向けて作業したい場合は、2.0.1d1、2.0.1d2、2.0.1d153、またはそれが必要なものから始めて、2.0.1a1をQAに送信し、2.0.1a37を承認した後です。 、2.0.1b1を自発的なパンターに送信し、2.0.1b9がフィールドで1週間生き残った後、2.0.1fc1を焼き、サインオフを取得し始めます。 2.0.1fc17が十分になると、2.0.1になり、多くの喜びがあります。

この形式は十分に標準化されているため、パックされたバイナリ形式と、比較を行うためのライブラリ内のヘルパールーチンがあります。

6
Tom Anderson

たくさんの記事/ QA/FAQ /本を読んだ後、[MAJOR]。[MINOR]。[REV]が最も便利なバージョン管理だと思うようになりましたプロジェクトバージョン間の互換性を説明するスキーマ（開発者向けのバージョン管理スキーマ、マーケティング向けではありません）。

[〜＃〜] major [〜＃〜]の変更には下位互換性がなく、プロジェクト名、ファイルへのパス、GUIDなどを変更する必要があります。

[〜＃〜]マイナー[〜＃〜]の変更には下位互換性があります。新機能の紹介をマークします。

[〜＃〜] rev [〜＃〜]セキュリティ/バグ修正用。後方互換性と前方互換性。

このバージョン管理スキーマは、libtoolバージョン管理セマンティクスと記事に触発されています。

http://www106.pair.com/rhp/parallel.html

注：build/date/custom/qualityとして提供することもお勧めします追加情報（ビルド番号、ビルド日付、顧客名、リリース品質）：

こんにちはアプリv2.6.34for国立銀行、2011-05-03、beta、ビルド23545

しかし、この情報はnotバージョン情報です！

4
gavenkoa

バージョン番号スキーム（x.y.0とx.yなど）は、外部要因によって制約される可能性があることに注意してください。

Git 1.9（2014年1月）の発表 ：

リリース候補のGitv1.9-rc2が、通常の場所でテストできるようになりました。

さまざまなサードパーティツールが2桁のバージョン番号を好まないという噂を聞いたことがあります（例：「Git2.0」）そして、ユーザーがv1.9-rc1をインストールすると、左右にバーフィングを開始しました。
彼らのずさんな仮定のために彼らを笑わせたくなりますが、私も実用的であり、彼らを助けるために次のリリースv1.9.0を呼び出すことを気にしません。

そのルートに行くと（そして私は現時点でそのルートに行く傾向があります）、バージョン管理スキームは次のようになります。

  • 次のリリース候補は、v1.9.0-rc3ではなくv1.9-rc3になります。
  • v1.9.0の最初のメンテナンスリリースはv1.9.1になります（そしてN番目はv1.9.Nになります）。そして
  • V1.9.0以降の機能リリースは、私たちが見ている機能ジャンプの大きさに応じて、v1.10.0またはv2.0.0のいずれかになります。
0
VonC