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

Question

これはばかげた質問かもしれませんが、ピリオドで表された各数字はソフトウェアの単一のコンポーネントを表していると私はいつも思っていました。それが本当なら、彼らは何か違うものを表現したことがありますか？ソフトウェアのさまざまなビルドにバージョンを割り当て始めたいのですが、どのように構成する必要があるのかよくわかりません。私のソフトウェアには5つの異なるコンポーネントがあります。

score 235 · Accepted Answer

バージョン1.9.0.1 では:

1 : 大幅な改訂（新しいUI、多くの新機能、概念の変更など）
9 : マイナーリビジョン (おそらく検索ボックスの変更、1 つの機能追加、バグ修正の収集)
0 : バグ修正リリース
1 : ビルド番号 (使用されている場合) - 2.0.4.2709 のようなものを使用して .NET フレームワークが表示されるのはそのためです。

4 レベルにまで下がっているアプリは多くありませんが、通常は 3 で十分です。

score 44 · Accepted Answer

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

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

バージョン番号 MAJOR.MINOR.PATCH を指定すると、次の値がインクリメントされます。

互換性のない API の変更を行った場合のメジャーバージョン、

下位互換性のある方法で機能を追加する場合の MINOR バージョン、および

下位互換性のあるバグ修正を行う場合の PATCH バージョン。

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

score 17 · Accepted Answer

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

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

score 12 · Accepted Answer

12

major.minor [.maintenance [.build]]

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

于 2008-09-15T19:04:19.530 に答える

score 9 · Accepted Answer

数字は他の回答で説明されているように役立つ場合がありますが、どのように意味がないかを検討してください... Sun、SUN、java：1.2、1.3、1.4 1.5、または5、6。古き良きAppleIIバージョン番号では意味があります何か。今日、人々はバージョン番号をあきらめ、「Feisty fig」（またはそのようなもの）、「hardy heron」、「europa」、「ganymede」などのばかげた名前を付けています。もちろん、これはあまり役に立ちません。なぜなら、プログラムの変更をやめる前に木星の衛星が不足し、明確な順序がないため、どちらが新しいかわからないからです。

score 8 · Accepted Answer

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

たとえば、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 は重要なリリースであり、一般的に新機能です。

score 3 · Accepted Answer

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

score 3 · Accepted Answer

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

score 2 · Accepted Answer

2

通常、その：

MajorVersion.MinorVersion.Revision.Build

于 2008-09-15T19:04:46.330 に答える

score 2 · Accepted Answer

場合によりますが、典型的な表現はmajor.minor.release.buildです。

どこ：

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

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

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

score 2 · Accepted Answer

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

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

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

軽微な変更とは、新しい機能を追加するが、プログラムに大きな変更を加えない変更です。

メジャーとは、古い機能を壊すか、ユーザーがプログラムを使用する方法を何らかの形で変更するほど大きなプログラムの変更です。

score 2 · Accepted Answer

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

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

「2」はシリーズ内でのリリースを示します。多くの場合、私たちはこの立場を利用して、前回のメジャーリリースに含まれていなかった機能に追いつくことができます。この位置 (2) は、ほとんどの場合、バグ修正を含む機能の追加を示します。

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

「3」の位置を超えて？なぜ人々がそのようなことをするのか、私には見当がつかない。

特に、そこにあるOSSのいくつかは、これらすべてを狂気に投げ出します。たとえば、Trac のバージョン 10 は実際には 0.10.XX です。OSS の世界の多くの人々は、自信がないか、メジャーリリースが完了したことを発表したくないだけだと思います。

score 1 · Accepted Answer

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

score 1 · Accepted Answer

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

一部のエンタープライズサポート契約では、特定のリリースの指定方法に関連付けられた $$$ (または契約責任の違反) があります。たとえば、契約では、一定期間内に一定数のメジャーリリースを利用する権利を顧客に与えたり、一定期間内のマイナーリリースの数が x 未満になることを約束したり、非常に多くのリリースに対して引き続きサポートを利用できることを約束したりする場合があります。リリースします。もちろん、メジャーリリースとマイナーリリースの違いを説明するために契約書にどれだけ多くの言葉を入れても、それは常に主観的なものであり、常に灰色の領域が存在します。ソフトウェアベンダーがシステムを操作して、そのような契約条項を破ります。

score 1 · Accepted Answer

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

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

score 1 · Accepted Answer

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

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

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

score 1 · Accepted Answer

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

score 1 · Accepted Answer

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.*")]

score 1 · Accepted Answer

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

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

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

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

根拠についてはこちらに詳しく書いています。

score 0 · Accepted Answer

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

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

score 0 · Accepted Answer

使用するものは次のとおりです。

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

すべての数字には明確で重要な機能があるため、このシステムはうまく機能しています。他のチームがメジャーナンバー/マイナーナンバーの問題 (どの程度の変更がメジャーか) に取り組んでいるのを見てきましたが、それによるメリットはないと思います。データベースのリビジョンを追跡する必要がない場合は、3 桁または 2 桁のバージョン番号に移動してください。

score 0 · Accepted Answer

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

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

score 0 · Accepted Answer

言語によって少し異なります。たとえば、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」を使用します。

score 0 · Accepted Answer

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

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

次は通常、ビルド番号と呼ばれます。これは、毎日、または「リリースされた」ビルドごとに、またはビルドごとにインクリメントされる場合があります。ビルド番号のみが異なり、通常はうまく連携できる 2 つのコンポーネントの間にはわずかな違いしかない場合があります。

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

バージョン番号をインクリメントするときは自由ですが、常にインクリメントするか、同じままにする必要があります。すべてのコンポーネントで同じバージョン番号を共有することも、変更されたコンポーネントのバージョン番号のみをインクリメントすることもできます。

score 0 · Accepted Answer

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

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

最初の番号はメインリリースです。ユーザーインターフェイスに大幅な変更を加えるか、既存のインターフェイスを壊す必要がある場合 (ユーザーがインターフェイスコードを変更する必要があるため)、新しいメインバージョンに移行する必要があります。
2 番目の数字は、新しい機能が追加されたか、内部で何かが異なって動作することを示す必要があります。(たとえば、Oracle データベースは、データを取得するために別の戦略を使用することを決定し、ほとんどのものを高速にし、一部のものを低速にすることを決定する場合があります。) 既存のインターフェイスは引き続き機能し、ユーザーインターフェイスは認識できる必要があります。
さらにバージョンの番号付けは、ソフトウェアの作成者次第です。Oracle は 5 つの (!) グループを使用します。Oracle のバージョンは 10.1.3.0.5 のようなものです。3 番目のグループからは、バグ修正または機能の小さな変更のみを導入する必要があります。

score 0 · Accepted Answer

変化の少ないものは、major.minor の最初の 2 つです。その後は、ビルド、リビジョン、リリースから任意のカスタムアルゴリズム (一部の MS 製品のように) まで何でもかまいません。

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

29 に答える 29

Related

Reference