バージョンの数字は通常何を表していますか（例：v1.9.0.1）？

多分これはばかげた質問かもしれませんが、私は常に、ピリオドで区切られた各数値がソフトウェアの単一のコンポーネントを表していると想定してきました。それが本当なら、彼らは何か違うことを表していますか？ソフトウェアの異なるビルドへのバージョンの割り当てを開始したいのですが、どのように構成する必要があるのか​​本当にわかりません。私のソフトウェアには5つの異なるコンポーネントがあります。

バージョン1.9.0.1の場合：

• 1：メジャーリビジョン（新しいUI、多くの新機能、概念の変更など）

• 9：マイナーリビジョン（検索ボックスの変更、1つの機能の追加、バグ修正のコレクション）

• 0：バグ修正リリース

• 1：ビルド番号（使用する場合）— 2.0.4.2709のようなものを使用する.NETフレームワークが表示されるのはそのためです

あなたは多くのアプリが4つのレベルに落ちることを見つけることができません、通常3つで十分です。

セマンティックバージョニング仕様があります

これはバージョン2.0.0の概要です。

バージョン番号MAJOR.MINOR.PATCHを指定して、次の値を増やします。

1. 互換性のないAPI変更を行った場合のメジャーバージョン
2. 下位互換性のある方法で機能を追加する場合のマイナーバージョン
3. 下位互換性のあるバグ修正を行う場合のパッチバージョン。

プレリリースおよびビルドメタデータの追加のラベルは、MAJOR.MINOR.PATCH形式の拡張機能として利用できます。

これは非常に恣意的であり、製品ごとに異なります。たとえば、Ubuntuディストリビューションでは、8.04は2008を指します。

通常、左端の（メジャー）番号はメジャーリリースを示し、右側に行くほど、関連する変更が小さくなります。

major.minor [.maintenance [.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

ポイントが多いほど、リリースはマイナーになります。それ以外に本当の確固たる基準はありません-プロジェクトのメンテナが何を決定するかに基づいて異なることを意味する可能性があります。

たとえば、WordPressは次の行に沿っています。

1.6-> 2.0-> 2.0.1-> 2.0.2-> 2.1-> 2.1.1-> 2.2 ...

1.6から2.0は大きなリリースになります-機能、インターフェースの変更、APIへの大きな変更、一部の1.6テンプレートとプラグインの破損など。2.0から2.0.1はマイナーリリース-おそらくセキュリティバグを修正します。2.0.2から2.1は重要なリリースです-一般に新機能。

番号は他の回答で説明されているように役立つ場合がありますが、あまり意味がない場合があることも考慮してください。Sun、Java、SUN、1.2、1.3、1.4 1.5または5を知っています。何か。現在、人々はバージョン番号をあきらめ、「Feisty fig」（またはそのようなもの）、「hardy heron」、「europa」、「ganymede」などの愚かな名前を付けています。もちろん、プログラムの変更をやめる前に木星の月が不足し、明確な順序がないのでどちらが新しいかわからないので、これはあまり役に立ちません。

バージョンv1.9.0.1の場合： これは、プレリリースの名前を使用したくない場合、または-alpha、-betaのようにビルドしたくない場合に使用される明示的なバージョン管理スキームです。

1：下位互換性を損なう可能性があるメジャーバージョン

9：以前のバージョンとの下位互換性とともに、アプリをサポートするための新機能の追加。

0：いくつかのマイナーなバグ修正

1：ビルド番号（プレリリース番号）

しかし、今日では、このようなバージョン管理スキームは見つかりません。セマンティックバージョニング[semver2.0]を 参照してくださいhttps://semver.org/

バージョン番号は通常、個別のコンポーネントを表すものではありません。一部の人/ソフトウェアでは、数値はかなり恣意的です。他のバージョンでは、バージョン番号文字列の異なる部分が異なるものを表します。たとえば、一部のシステムでは、ファイル形式が変更されると、バージョン番号の一部が増加します。したがって、V 1.2.1は他のすべてのV 1.2バージョン（1.2.2、1.2.3など）と互換性のあるファイル形式ですが、V 1.3とは互換性がありません。最終的には、どのスキームを使用するかはあなた次第です。

通常は：

MajorVersion.MinorVersion.Revision.Build

状況によって異なりますが、典型的な表現はmajor.minor.release.buildの表現です。

どこ：

• majorは、ソフトウェアのメジャーリリースバージョンです。.NET3.xと考えてください。
• minorはソフトウェアのマイナーリリースバージョンです。.NETx.5と考えてください。
• releaseはそのバージョンのリリースです。通常、バグ修正によりこれが増加します
• buildは、実行したビルドの数を示す数値です。

したがって、たとえば1.9.0.1は、ソフトウェアのバージョン1.9であることを意味し、1.8や1.7などに従います。1.7、1.8および1.9は、通常、何らかの方法でバグ修正とともに少量の新機能を追加します。それはxx0.xなので、1.9の最初のリリースであり、そのバージョンの最初のビルドです。

また、この件に関するウィキペディアの記事で、良い情報を見つけることができます。

メジャー、マイナー、バグ

（またはそのいくつかのバリエーション）

バグは通常、新機能のないバグ修正です。

マイナーとは、新しい機能を追加するいくつかの変更ですが、プログラムに大きな変更は加えません。

メジャーなのはプログラムの変更であり、古い機能を破壊するか、非常に大きいため、ユーザーがプログラムを使用する方法が何らかの形で変更されます。

誰もがこれらの数字で何をしたいかを選択します。とにかくばかげているので、releasesをabcと呼びたくなります。そうは言っても、私が過去25年以上の開発で見たものは、このように機能する傾向があります。バージョン番号が1.2.3だとしましょう。

「1」は「メジャー」リビジョンを示します。通常、これは初期リリース、大規模な機能セットの変更、またはコードの重要な部分の書き換えです。機能セットが決定され、少なくとも部分的に実装されたら、次の番号に進みます。

「2」はシリーズ内のリリースを示します。多くの場合、この位置を使用して、前回のメジャーリリースでは実現できなかった機能に追いつきます。この位置（2）は、ほとんどの場合、機能の追加を示し、通常はバグが修正されています。

ほとんどのショップの「3」は、パッチリリース/バグ修正を示しています。少なくとも商業的な側面では、これが重要な機能の追加を示すことはほとんどありません。機能が3の位置に表示される場合は、バグ修正リリースを行う必要があることを知る前に誰かが何かをチェックインしたことが原因であると考えられます。

「3」の位置を超えて？なぜ人々がそのようなことをするのか、私には手がかりがなく、混乱を招くだけです。

特に、世の中にあるOSSのいくつかは、これらすべてを無意味に捨てています。たとえば、Tracバージョン10は実際には0.10.XXです。OSSの世界の多くの人々は、自信がないか、メジャーリリースが完了したことを知らせたくないと思います。

C＃AssemblyInfo.csファイルから、以下を確認できます。

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

release.major.minor.revisionが私の推測です。
ただし、製品によって大きく異なる場合があります。

Major.minor.point.build通常。メジャーとマイナーは自明であり、ポイントはいくつかのマイナーなバグ修正のリリースであり、ビルドは単なるビルド識別子です。

うん。メジャーリリースでは、大きな新しい機能が追加されたり、互換性が失われたり、依存関係が大幅に異なる場合があります。

マイナーリリースにも機能が追加されていますが、ベータメジャーリリースからより小さく、時には移植されたバージョンが削除されています。

3番目のバージョン番号コンポーネントがある場合、それは通常、重要なバグ修正とセキュリティ修正のためのものです。それ以上あると本当に製品に依存しすぎて一般的な答えが難しい。

メジャーリリース、マイナーリリース、バグ修正のパラダイムはかなり一般的だと思います。

一部のエンタープライズサポート契約では、特定のリリースの指定方法に関連する$$$（または契約責任の違反）があります。たとえば、契約では、ある期間内にいくつかのメジャーリリースを顧客に提供したり、期間内にx未満のマイナーリリースが存在することを約束したり、サポートを非常に多く提供したりすることができます。リリース。もちろん、メジャーリリースとマイナーリリースの違いを説明するために契約にいくつの単語を入れても、それは常に主観的であり、常に灰色の領域が存在します。ソフトウェアベンダーがシステムをゲームする可能性があります。そのような契約上の規定を破った。

2.1、2.0.1、2.10のようなバージョン番号の微妙な違いを常に認識しているわけではありません。テクニカルサポート担当者に何回問題があったか尋ねてください。開発者は詳細指向で階層構造に精通しているため、これは私たちにとって盲点です。

可能であれば、より簡単なバージョン番号を顧客に公開してください。

ライブラリの場合、バージョン番号は互換性のレベルを示します 2つのリリース間を示し、アップグレードがどれほど難しいかを示します。

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

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

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

理論的根拠については、こちらで詳しく書いた。

メジャー、マイナー、パッチ、ビルド、セキュリティパッチなどの組み合わせ。

最初の2つはメジャーとマイナーです。残りはプロジェクト、会社、そして時にはコミュニティに依存します。FreeBSDのようなOSでは、セキュリティパッチを表す1.9.0.1_numberがあります。

言語によって多少異なりますが、たとえばDelphiとC＃の意味は異なります。

通常、最初の2つの数字はメジャーバージョンとマイナーバージョンを表します。つまり、最初の実際のリリースでは1.0、重要なバグ修正とマイナーな新機能では1.1、大きな新機能リリースでは2.0です。

3番目の番号は、「本当にマイナー」なバージョンまたはリビジョンを指します。1.0.1は、たとえば1.0.0に対する非常に小さなバグ修正です。しかし、ソース管理システムからのリビジョン番号、またはビルドごとに増加する常に増加する番号を運ぶこともできます。または日付スタンプ。

少しは詳細ビットこちら。「公式」には、.netでは4つの数値は「Major.Minor.Build.Revision」ですが、Delphiでは「Major.Minor.Release.Build」です。私はバージョン管理に「Major.Minor.ReallyMinor.SubversionRev」を使用しています。

通常、番号はversion.major.minor.hotfixの形式であり、個々の内部コンポーネントではありません。したがって、v1.9.0.1はバージョン1、メジャーリリース9（v1）、マイナーリリース（v1.9）0、ホットフィックス1（v1.9.0）になります。

通常、最初の番号はメジャーバージョン番号と呼ばれます。基本的には、ビルド間の重要な変更を示すために使用されます（つまり、多くの新機能を追加すると、メジャーバージョンが増加します）。同じ製品のメジャーバージョンが異なるコンポーネントは互換性がない可能性があります。

次の番号はマイナーバージョン番号です。これは、いくつかの新機能、またはいくつかのバグ修正や小さなアーキテクチャの変更を表すことができます。マイナーバージョン番号が異なる同じ製品のコンポーネントは、一緒に機能する場合と機能しない場合があり、おそらく機能しません。

次は通常ビルド番号と呼ばれます。これは、毎日、または「リリースされた」ビルドごとに、またはビルドごとに増分される可能性があります。ビルド番号のみが異なり、通常は一緒に機能する2つのコンポーネント間には、わずかな違いしかない場合があります。

最終的な番号は通常、リビジョン番号です。多くの場合、これは自動ビルドプロセスによって、またはテストのために「1回限り」の使い捨てビルドを作成するときに使用されます。

バージョン番号をインクリメントするかどうかはユーザー次第ですが、バージョン番号は常にインクリメントするか、そのままにする必要があります。すべてのコンポーネントで同じバージョン番号を共有するか、変更されたコンポーネントのバージョン番号のみを増やすことができます。

複雑なソフトウェアのバージョン番号はパッケージ全体を表し、パーツのバージョン番号とは無関係です。Gizmoバージョン3.2.5には、Fooバージョン1.2.0およびBarバージョン9.5.4が含まれている場合があります。

バージョン番号を作成するときは、次のように使用します。

1. 最初の番号はメインリリースです。ユーザーインターフェイスに大幅な変更を加えたり、既存のインターフェイスを解除する必要がある場合（ユーザーがインターフェイスコードを変更する必要がある場合）は、新しいメインバージョンに移行する必要があります。

2. 2番目の数字は、新しい機能が追加されているか、内部で動作が異なることを示しています。（たとえば、Oracleデータベースは、データを取得するために別の戦略を使用することを決定し、ほとんどのものをより速くし、いくつかのものを遅くするかもしれません。）

3. バージョンの番号付けは、ソフトウェアの作成者次第です-Oracleは5つの（！）グループを使用します。Oracleのバージョンは10.1.3.0.5のようなものです。3番目のグループから、バグ修正または機能のマイナーな変更のみを導入する必要があります。

変化が少ないものは、major.minorの場合、最初の2つになります。その後、ビルド、リビジョン、リリース、カスタムアルゴリズム（一部のMS製品など）まで何でも可能です。

すべての組織/グループには独自の基準があります。重要なことは、選択した表記に固執することです。そうしないと、顧客が混乱します。とは言っても、私は通常3つの数値を使用しました。

x.yz.bbbbb。ここで：x：はメジャーバージョン（メジャーな新機能）y：はマイナーバージョン番号（小さな新機能、UIを変更せずに小さな改善）z：はサービスパック（基本的にxyと同じですが、いくつかのバグ修正はありますbbbb：はビルド番号であり、「アバウトボックス」からのみ実際に表示され、カスタマーサポートのその他の詳細が表示されます。bbbbはフリーフォーマットであり、すべての製品が独自のものを使用できます。

これが私たちが使うものです：

1. 最初の番号=システム全体の時代。数年ごとに変更され、通常、テクノロジー、クライアント機能、またはその両方の根本的な変更を表します。
2. 2番目の番号=データベーススキーマリビジョン。この数を増やすにはデータベースの移行が必要であり、それによって大幅な変更が行われます（またはシステムが複製され、データベース構造を変更するには慎重なアップグレードプロセスが必要です）。最初の数値が変更されると、0にリセットされます。
3. 3番目の番号=ソフトウェアのみの変更。データベーススキーマは変更されていないため、これは通常クライアントごとに実装できます。2番目の数値が変更されると、ゼロにリセットされます。
4. Subversionのバージョン番号。TortoiseSVNツールを使用して、ビルド時にこれを自動的に入力します。この数はリセットされず、継続的に増加します。これを使用して、いつでも任意のバージョンを再作成できます。

すべての数値に明確で重要な機能があるため、このシステムは私たちに役立ちます。他のチームがメジャー番号/マイナー番号の質問（変更がどれほど大きいか）に取り組んでいるのを見たことがありますが、そのメリットはわかりません。データベースのリビジョンを追跡する必要がない場合は、3桁または2桁のバージョン番号に移動するだけで、作業が楽になります。

バージョン：v1.9.0.1

どこ-

。vはバージョンの省略形です。それは彼の組織で採用された命名法に依存する会社ごとに異なります。1.9.0.1のような一部の組織ではサイレントになる場合があります

。1はメジャーバージョンを示し、アプリケーションスタック、インフラストラクチャ（プラットフォーム）、または公開されたネットワークインターフェイスのアーキテクチャの変更時に更新されます

。9はマイナーを含み、UI、API、データベースなどの新しいコンポーネントの追加などのアクティビティで更新されます。特定のアーキテクチャの下で

。0は機能を示し、既存のコンポーネント（ui、api、データベースなど）の拡張機能で更新されます

。1は、メジャー、マイナー、機能のすべてのフェーズでビルドカウンターを示します。また、ポストプロダクションリリースの修正プログラムも含まれています。