29

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

たとえば、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バージョンスキームに従わないでください...

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

4

5 に答える 5

26

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

http://semver.org/

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

于 2010-01-12T11:37:37.500 に答える
24

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

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

于 2010-01-12T11:27:55.163 に答える
6

完全を期すために、バージョン番号に関する古い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がフィールドで一週間生き残った後、2.0.1fc1を燃やし、サインオフを開始します。2.0.1fc17が十分になると、2.0.1になり、多くの喜びがあります。

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

于 2012-04-27T16:09:34.977 に答える
4

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

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

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

セキュリティ/バグ修正のためのREV 。後方互換性と前方互換性。

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

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

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

国立銀行のこんにちはアプリv2.6.34、2011-05-03、ベータ版、ビルド23545

しかし、この情報はバージョン情報ではありません！

于 2011-10-11T18:24:00.603 に答える
1

バージョン番号スキーム（x.y.0vs.など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のいずれかになります。
于 2014-02-04T07:30:33.143 に答える