バージョンの数字は通常何を表しますか（つまりv1.9.0.1）？
たぶんこれはばかげた質問かもしれませんが、私はいつも、ソフトウェアの単一のコンポーネントを表す期間で区切られた各数字を想定していました。それが本当なら、彼らは今までとは違う何かを表していますか？ソフトウェアの異なるビルドにバージョンを割り当てたいのですが、どのように構成する必要があるのかよくわかりません。私のソフトウェアには5つの異なるコンポーネントがあります。
バージョン1.9.0.1：
1：メジャーリビジョン（新しいUI、多くの新機能、概念の変更など）
9：マイナーリビジョン（検索ボックスの変更、1つの機能の追加、バグ修正のコレクション）
：バグ修正リリース
1：ビルド番号（使用する場合）—だから、2.0.4.2709のようなものを使用した.NETフレームワークが表示されます
4つのレベルに下がるアプリはあまりありません。通常は3つで十分です。
Semantic Versioning specification があります
これはバージョン2.0の要約です。
バージョン番号MAJOR.MINOR.PATCHを指定して、次の値を増やします。
MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.プレリリースおよびビルドメタデータの追加ラベルは、MAJOR.MINOR.PATCH形式の拡張機能として利用できます。
非常にarbitrary意的であり、製品ごとに異なります。たとえば、Ubuntuディストリビューションでは、8.04は2008.Aprilを指します
通常、左端の（メジャー）番号はメジャーリリースを示し、右に行くほど変更が少なくなります。
major.minor [.maintenance [.build]]
ポイントが多いほど、リリースはマイナーになります。それを超える本当の堅実な標準はありません-プロジェクトのメンテナーが何を決定するかに基づいて異なることを意味する可能性があります。
たとえば、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は重要なリリースであり、一般的に新機能です。
数字はあなたが望むものを意味しますが、通常は個々のコンポーネントに関係するのではなく、リリースのメジャー変更対マイナー変更対メンテナンス変更に関係します。
以下のリソースをご覧ください。
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html
乾杯
通常、バージョン番号は個別のコンポーネントを表すものではありません。一部の人々/ソフトウェアにとって、数字はかなりfairly意的です。その他の場合、バージョン番号文字列の異なる部分は異なるものを表します。たとえば、一部のシステムでは、ファイル形式が変更されるとバージョン番号の一部が増加します。したがって、V 1.2.1は他のすべてのV 1.2バージョン（1.2.2、1.2.3など）と互換性のあるファイル形式ですが、V 1.3とは互換性がありません。最終的には、どのスキームを使用するかはあなた次第です。
誰もがこれらの数字で何をしたいかを選択します。とにかくかなり馬鹿げているので、リリースa.b.cを呼び出したいと思いました。そうは言っても、過去25年以上の開発で私が見たものは、このように機能する傾向があります。バージョン番号が1.2.3だとしましょう。
「1」は「メジャー」リビジョンを示します。通常、これは初期リリース、大きな機能セットの変更、またはコードの重要な部分の書き換えです。機能セットが決定され、少なくとも部分的に実装されたら、次の番号に進みます。
「2」は、シリーズ内のリリースを示します。多くの場合、この位置を使用して、前回のメジャーリリースで達成できなかった機能に追いつきます。この位置（2）は、ほとんどの場合、機能の追加を示しており、通常はバグが修正されています。
ほとんどのショップの「3」は、パッチリリース/バグ修正を示しています。少なくとも商業的な面では、これが重要な機能の追加を示すことはほとんどありません。位置3に機能が表示される場合は、おそらくバグ修正リリースを行う必要があると知る前に誰かが何かをチェックインしたことが原因です。
「3」の位置を超えて？なぜ人々がそのようなことをするのか、私には見当がつかず、単に混乱を招くだけです。
特に、そこにあるOSSの一部は、これらすべてをおかしなものにしています。たとえば、Tracバージョン10は実際には0.10.X.Xです。 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は私の推測でしょう。
ただし、製品によって大きく異なる場合があります。
通常：
MajorVersion.MinorVersion.Revision.Build
依存しますが、典型的な表現はmajor.minor.release.buildです。
どこ：
- majorは、ソフトウェアのメジャーリリースバージョンです。NET3.xと思います
- minorは、ソフトウェアのマイナーリリースバージョンです。NETx.5と思います
- releaseはそのバージョンのリリースです。通常、バグ修正によりこれが増加します
- buildは、実行したビルドの数を示す数値です。
したがって、たとえば1.9.0.1は、1.8および1.7などに続くバージョン1.9のソフトウェアであることを意味します。通常、1.7、1.8および1.9は何らかの形で、バグ修正とともに少量の新機能を追加します。 x.x.0.xであるため、1.9の最初のリリースであり、そのバージョンの最初のビルドです。
このテーマに関するウィキペディアの記事 でも良い情報を見つけることができます。
Major.Minor.Bugs
（またはそのバリエーション）
バグは通常、新しい機能のないバグ修正です。
マイナーとは、新しい機能を追加する変更ですが、プログラムに大きな変更を加えるものではありません。
メジャーとは、古い機能を破壊するか、ユーザーがプログラムを使用する方法を何らかの形で変更するほど大きいプログラムの変更です。
2.1、2.0.1、2.10などのバージョン番号の微妙な違いを常に認識しているわけではありません。技術サポート担当者に、これで何回問題が発生したかを尋ねてください。開発者は詳細指向であり、階層構造に精通しているため、これは私たちにとって盲点です。
可能な限り、よりシンプルなバージョン番号を顧客に公開します。
メジャーrelease.minor release.bug修正のパラダイムはかなり一般的だと思います。
一部のエンタープライズサポート契約では、特定のリリースの指定方法に関連する$$$（または契約責任の違反）があります。たとえば、契約は、ある期間に顧客にいくつかのメジャーリリースの資格を与えるか、期間内にx個未満のマイナーリリースがあることを約束するか、または多くの人が引き続きサポートを利用できることを約束します。リリース。もちろん、メジャーリリースとマイナーリリースを説明するために契約にいくつの言葉を入れても、常に主観的であり、常に灰色の領域が存在するため、ソフトウェアベンダーはシステムをゲームできる可能性があります。そのような契約条項を破ります。
ライブラリの場合、バージョン番号は2つのリリース間の互換性のレベルを示しているため、アップグレードがどれほど難しいかがわかります。
バグ修正リリースでは、バイナリ、ソース、およびシリアル化の互換性を維持する必要があります。
マイナーリリースはプロジェクトごとに異なることを意味しますが、通常はソースの互換性を維持する必要はありません。
メジャーバージョン番号は、3つの形式すべてを破壊する可能性があります。
原理についてもっと書いた here 。
バージョンv1.9.0.1：これは、プレリリースに名前を使用したり、-alpha、-betaのようなビルドをしたくない場合に使用される明示的なバージョン管理スキームです。
1：下位互換性を壊す可能性のあるメジャーバージョン
9：アプリをサポートするための新機能の追加と、以前のバージョンとの後方互換性。
0：いくつかのマイナーなバグ修正
1：ビルド番号（プレリリース番号）
しかし、最近では、このようなバージョン管理スキームは見つかりません。セマンティックバージョニング[semver2.0]を参照してください https://semver.org/
Major.minor.point.build通常。メジャーとマイナーは自明であり、ポイントはいくつかのマイナーなバグ修正のリリースであり、ビルドは単なるビルド識別子です。
うん。メジャーリリースでは、大きな新しい機能が追加され、互換性が損なわれたり、依存関係が大幅に異なる場合があります。
マイナーリリースも機能を追加しますが、それらはより小さく、ベータメジャーリリースから移植されたバージョンです。
3番目のバージョン番号コンポーネントがある場合、通常は重要なバグ修正とセキュリティ修正のためです。それ以上ある場合、それは本当に製品に大きく依存しているため、一般的な答えを出すのは困難です。
最初の番号は通常、メジャーバージョン番号と呼ばれます。基本的に、ビルド間の重要な変更を示すために使用されます（つまり、多くの新しい機能を追加すると、メジャーバージョンが増加します）。同じ製品のメジャーバージョンが異なるコンポーネントは、おそらく互換性がありません。
次の番号はマイナーバージョン番号です。いくつかの新機能、または多数のバグ修正または小さなアーキテクチャの変更を表すことができます。マイナーバージョン番号が異なる同じ製品のコンポーネントは、一緒に動作する場合と動作しない場合があり、おそらく動作しないはずです。
次は通常ビルド番号と呼ばれます。これは毎日、または「リリース済み」ビルドごとに、またはビルドごとに増分されます。ビルド番号のみが異なる2つのコンポーネント間にはわずかな違いしかなく、通常は一緒に機能します。
通常、最終番号はリビジョン番号です。多くの場合、これは自動ビルドプロセスで使用されるか、テストのために「1回限り」の使い捨てビルドを作成するときに使用されます。
バージョン番号をインクリメントするのはあなた次第ですが、常にincrementまたはstay the sameにする必要があります。すべてのコンポーネントで同じバージョン番号を共有することも、変更されたコンポーネントのバージョン番号のみを増やすこともできます。
複雑なソフトウェアのバージョン番号はパッケージ全体を表し、パーツのバージョン番号には依存しません。 Gizmoバージョン3.2.5には、Fooバージョン1.2.0およびBarバージョン9.5.4が含まれる場合があります。
バージョン番号を作成するときは、次のように使用します。
最初の番号はメインリリースです。ユーザーインターフェイスに大幅な変更を加えるか、既存のインターフェイスを中断する必要がある場合（ユーザーがインターフェイスコードを変更する必要があるように）、新しいメインバージョンに移動する必要があります。
2番目の数字は、新しい機能が追加されたか、内部で何かが異なる動作をしていることを示す必要があります。 （たとえば、Oracleデータベースは、データを取得するために別の戦略を使用して、ほとんどの処理を高速化し、一部の処理を低速化することを決定する場合があります。）.
バージョンの番号付けは、ソフトウェアの作成者次第です。Oracleは5つの（！）グループを使用します。 Oracleバージョンは10.1.3.0.5のようなものです。 3番目のグループから、バグ修正または機能の小さな変更のみを導入する必要があります。
major.minorの場合、変化の少ないものは最初の2つであり、その後、ビルド、リビジョン、リリース、カスタムアルゴリズム（一部のMS製品など）になります。
使用するものは次のとおりです。
- 最初の数字=システム全体の時代。数年ごとに変化し、通常、技術、またはクライアント機能、またはその両方の根本的な変化を表します。
- 2番目の番号=データベーススキーマリビジョン。この数を増やすには、データベースの移行が必要であるため、大幅な変更が必要です（またはシステムが複製されるため、データベース構造を変更するには慎重なアップグレードプロセスが必要です）。最初の数値が変更されると、0にリセットされます。
- 3番目の数字=ソフトウェアのみ変更。これは通常、データベーススキーマが変更されていないため、クライアントごとにクライアントに実装できます。 2番目の数値が変更されると、ゼロにリセットされます。
- Subversionバージョン番号。 TortoiseSVNツールを使用して、ビルド時にこれを自動的に設定します。この数値は決してリセットされず、継続的に増加します。これを使用して、いつでもどのバージョンでも再作成できます。
すべての数字には明確で重要な機能があるため、このシステムは私たちにうまく機能しています。他のチームがメジャー番号/マイナー番号の質問（どれだけ大きな変更がメジャーであるか）に取り組んでいるのを見たことがありますが、その利点はわかりません。データベースのリビジョンを追跡する必要がない場合は、3桁または2桁のバージョン番号に移動するだけで、作業が楽になります！
すべての組織/グループには独自の標準があります。重要なことは、選択した表記に固執することです。そうしないと、顧客は混乱します。私は通常3つの数字を使用したと言ったが：
x.yz.bbbbb。ここで、x：はメジャーバージョン（主要な新機能）y：はマイナーバージョン番号（小さな新機能、UIの変更なしの小さな改善）z：はサービスパック（基本的にxyと同じですが、いくつかのバグ修正bbbb：ビルド番号であり、カスタマーサポート用の他の詳細とともに「アバウトボックス」からのみ実際に表示されます.bbbbはフリーフォーマットであり、すべての製品が独自のものを使用できます。
メジャー、マイナー、パッチ、ビルド、セキュリティパッチなどの組み合わせ.
最初の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）になります。