これは私がいつも疑問に思っていたものです...
私の素朴さを許してください、しかし-あなたはどのようにあなたのソフトウェアに名前を付けるバージョン番号を決めるのですか？
誰かがアプリケーション/プログラムの「最終」バージョンを作成するとき、それはバージョン1.0だと思いますか？-次に、更新するとどうなりますか、1.1または1.03などとどのように呼ぶことにしますか。
これは主に開発者向けですか？
11183 次
12 に答える
54
私は最近、EricElliotのMediumアカウントで最初に遭遇したより巧妙なバージョン管理戦略を聞いた。顧客が直面しているバージョン番号よりもライブラリのバージョン管理に重点が置かれていますが、単純であるという利点があります。3つの部分からなるバージョン番号を使用します。各番号は、次のことを意味します。
Breaking.feature.fix
- 破壊：コード/期待を変更する必要があることを意味する何かが変更されました
- 機能：何か新しいものが追加されていますが、古いコード/期待値は引き続き正常に機能します。
- 修正：新しいものはありませんが、バグが修正されました。
私の古い答えは、顧客向けのバージョンにまだ関連しているので、以下に残しておきます。
私は有効数字を次のように重み付けする傾向があります。
wxyz（またはw.xyz）
- w-多くの新機能を備えたメジャーバージョン。有料アップグレード。ソフトウェアの最初のパブリックリリースは1.Xです（プレリリースバージョンは0.Xです）
- x-重要なリリースですが、画期的な新機能はありません。
- y-バグ修正リリース
- z-パッチレベルのリリース（おそらく1つのクライアントのみの緊急バグの修正）。
w.xyz形式を使用することを選択した場合、オーバーフローする前に取得できるのは9桁だけです。ただし、それを頻繁にリリースする場合は、より大きな問題が発生する可能性があります。
私の新製品であるFooAppで説明しましょう！
- 0.9-最初のパブリックベータ
- 0.91-2番目のパブリックベータ
- 0.911-Motorola68010のクラッシュを修正するための緊急ベータリリース
- 1.0-最初の公開リリース
- 1.1-新しいBlahBaz機能を追加しました
- 1.11-バグ修正
- 2.0-完全に再開発されたインターフェース。
于 2008-12-28T17:37:09.540 に答える
25
Jeff Atwoodがこれについてのブログ投稿をしており、ユーザーをバージョン番号と混同しないように、日付だけを使用することを提唱しています。ただし、彼はMicrosoftが採用したアプローチについて説明しています。日付を使用してバージョン番号を決定します。彼は彼の投稿でかなり深く掘り下げているので、ここで彼の仕事を複製することはしません。バージョン管理について：
バージョン（少なくとも.NETでは、次のようになります）：
1.2.3.4ここで：
1はメジャーリリース
2はマイナーリリース
3はビルド番号
4はリビジョン番号です
メジャーリリース-そのバージョンが持つことを意図した機能を備えた「完全な」システムを意味します。通常、後続の「メジャー」バージョンは、ソフトウェアの書き換え、アーキテクチャの変更、または（冗長性を失います）メジャーな変更です。
マイナーリリース-バグ修正、小さな機能の追加、またはその他の「マイナー」イベントがいくつも含まれている、それほど重要ではないリリースを意味します。これには、インターフェースの変更と追加が含まれる場合があります。通常、アプリケーションは「メジャーリリース」ツリーである程度互換性がある必要があるため、同じメジャーリリースのマイナーバージョンはアーキテクチャ的に同じである必要があります。
ビルド番号-通常、バグ修正と小さな修正だけを意味し、その範囲はやや重要ではありません。アプリの前景と背景のコントラストを変更するのと同じくらい簡単なことかもしれません。一般に、ビルドはナイトリービルドなどの内部指定であるため、常に安定した状態に戻す場所があります。
リビジョン番号-バグ修正がリリースされたとき、または非常にマイナーな機能強化が行われたときを示します。これらは通常、バグ修正のためだけに予約されています。主要な機能拡張をリビジョンとして含めないでください。
于 2008-12-28T17:45:47.667 に答える
9
アプリケーションの各ビルドには、Major.Minor.Maintenance.Buildとして定義された一意の4つの部分からなるバージョン番号を割り当てます。
メジャー-メジャー番号は、アプリケーションへの重要な変更に関連付けられています。この数は、同じ「スイート」内の他のアプリケーションとの互換性も決定します。この数は、新しいリリースが作成されるときに増加します。これは通常、主要なアーキテクチャの変更が行われたことを意味します。
マイナー-マイナー番号は、新機能と重大なバグ修正に関連付けられています。新しい機能が導入されたとき、または重大なバグ修正が適用されたときはいつでも、この番号が進められ、メンテナンス番号がゼロに設定されます。
メンテナンス-メンテナンス番号は、破損しないバグ修正に関連付けられています。この数は、ブレーク以外のバグ修正のみを含むリリースが作成されるたびに進められます。
ビルド-ビルド番号は、アプリケーションのコンパイル元のSubversionチェンジセット（リビジョン番号）に関連付けられています。これにより、バージョン番号をSubversionの正確なコードセットに簡単に一致させることができます。
開発者がこのスキームに本当に興味を持っているのはビルドだけです。番号。ビルド番号をSubversionリビジョン番号に関連付けることで、リリースされたアプリケーションの作成に使用されたコードを保証できます。
于 2008-12-28T17:52:49.243 に答える
8
Linuxカーネルはこれの良いリファレンスだと思います：
Linuxカーネルのバージョン番号は、3番号のバージョニングスキームの長年のポリシーの最近の変更に続いて、現在4つの番号で構成されています。説明のために、バージョン番号が次のように構成されていると仮定します：ABC [.D]（たとえば、2.2.1、2.4.13、または2.6.12.3）。
* The A number denotes the kernel version. It is rarely changed, andコードとカーネルの概念に大きな変更があった場合のみ。カーネルの歴史の中で、1994年（バージョン1.0）と1996年（バージョン2.0）の2回変更されました。
* The B number denotes the major revision of the kernel. o Prior to the Linux 2.6.x series, even numbers indicate a stableリリース、つまり、1.2、2.4、2.6などの本番環境での使用に適していると見なされるリリース。奇数は、歴史的に1.1や2.5などの開発リリースでした。それらは、安定したリリースに含まれるのに十分安定するまで、新しい機能とドライバーをテストするためのものでした。これは、偶数/奇数のバージョン番号スキームでした。o Linux 2.6.xシリーズ以降、偶数または奇数に意味はなく、同じカーネルシリーズで新機能の開発が行われています。リーナス・トーバルズは、これが予見可能な将来のモデルになると述べています。
* The C number indicates the minor revision of the kernel. In the old3番号バージョン管理スキーム。これは、セキュリティパッチ、バグ修正、新機能、またはドライバーがカーネルに実装されたときに変更されました。ただし、新しいポリシーでは、新しいドライバーまたは機能が導入された場合にのみ変更されます。マイナーな修正はD番号で処理されます。
* A D number first occurred when a grave error, which required immediate修正は、2.6.8のNFSコードで発生しました。ただし、新しいマイナーリビジョン（2.6.9であったはずです）のリリースを正当化するのに十分な他の変更はありませんでした。そのため、2.6.8.1がリリースされましたが、唯一の変更はそのエラーの修正です。2.6.11では、これが新しい公式のバージョン管理ポリシーとして採用されました。バグ修正とセキュリティパッチは4番目の番号で管理されるようになりましたが、大きな変更はマイナーなリビジョン変更（C番号）でのみ実装されます。D番号は、コンパイラがカーネルをビルドした回数にも関連付けられているため、「ビルド番号」と呼ばれます。
また、バージョンの後に、「rc1」や「mm2」などの文字が追加される場合もあります。「rc」はリリース候補を指し、非公式リリースを示します。他の文字は通常（常にではありませんが）人のイニシャルです。これは、その人によるカーネルの開発ブランチを示しています。たとえば、ckはCon Kolivasを表し、acはAlan Coxを表し、mmはAndrewMortonを表します。文字は、カーネルが構築されているブランチの主要な開発領域に関連している場合があります。たとえば、wlはワイヤレスネットワークのテストビルドを示します。
http://en.wikipedia.org/wiki/Linux_kernel#Version_numberingから
于 2008-12-28T17:39:08.040 に答える
4
どの番号付けスキームを選択する場合でも、新しいバージョンが古いクライアントコードと互換性がある場合と、新しいバージョンで既存のクライアントに変更が必要な場合をユーザーに明確にすることが重要です。私が知っているほとんどのプロジェクトは、クライアントコードを変更する必要があるときに、最初の数を増やします。
互換性を超えて、私も日付を使用するために言われることがたくさんあると思います。私のように、リリーススケジュールが2年に1回の場合は恥ずかしいことですが（ただし、これは1989年に最初にリリースされたツールの場合です）。
于 2008-12-28T18:10:28.320 に答える
2
おそらく、営業やマーケティングの誰かが、話題が必要だと判断するでしょう。これにより、次のリリースが1.01か1.1または2.0かが決まります。オープンソースでも同じように機能しますが、チームが誇る素晴らしい新機能に結びつく傾向があります。
于 2008-12-28T17:38:02.207 に答える
2
あいうえお
- A：ベータ版の場合は0、最初のリリースの場合は1、ほぼ全体の書き換えで1より大きい。
- B：追加された新機能
- C：バグ修正が行われました
- バージョン管理リポジトリのリビジョン番号
于 2008-12-28T17:43:56.843 に答える
2
これは、組み込みCプロジェクトのモジュールに使用するものです。
1.00-初期リリース
1.01-マイナーリビジョン
モジュールへのインターフェイスの変更はありません（つまり、ヘッダーファイルは変更されませんでした）。私のモジュールを使用している人は誰でも、コードを壊すことを恐れることなくアップグレードできます。リファクタリングやコードのクリーンアップを行った可能性があります。
2.00-メジャーリビジョン
モジュールインターフェイスが変更されました（つまり、機能が追加、削除、または特定の機能の機能が変更されました）。このリビジョンにアップグレードすると、既存のコードが破損する可能性が高く、このモジュールを使用してコードをリファクタリングする必要があります。
これは開発段階、つまりプロジェクトへのモジュールの内部リリースを指していることを付け加えておきます。
于 2008-12-28T17:47:44.310 に答える
2
上記のすべての説明に加えて、顧客が覚えやすく、ソフトウェア バージョンのベースラインと管理が容易なバージョン管理スキームを使用することをお勧めします。また、.Net 1.0、.Net1.1 などの別のフレームワークをサポートしている場合は、バージョン管理スキームもそれを処理するようにしてください。
于 2008-12-28T18:27:44.073 に答える
1
ここにもいくつかの良い情報があります。
ファイル/アセンブリのバージョンを変更する場合まず、ファイルのバージョンとアセンブリのバージョンが一致している必要はありません。ビルドごとにファイルバージョンを変更することをお勧めします。ただし、同じファイルの2つのバージョンの違いがわかるように、ビルドごとにアセンブリのバージョンを変更しないでください。そのためのファイルバージョンを使用してください。アセンブリのバージョンをいつ変更するかを決定するには、考慮すべきビルドのタイプ（出荷と非出荷）についていくつかの議論が必要です。
非出荷ビルド一般に、出荷ビルド間で非出荷アセンブリバージョンを同じに保つことをお勧めします。これにより、バージョンの不一致による厳密な名前のアセンブリの読み込みの問題が回避されます。パブリッシャーポリシーを使用して、ビルドごとに新しいアセンブリバージョンをリダイレクトすることを好む人もいます。ただし、出荷されていないビルドの場合は、これに反対することをお勧めします。すべてのロードの問題を回避できるわけではありません。たとえば、パートナーがアプリをxコピーした場合、パートナーはパブリッシャーポリシーをインストールすることを知らない可能性があります。そうすると、あなたのアプリはあなたのマシン上でうまく機能していても、彼らのために壊れてしまいます。
ただし、同じマシン上の異なるアプリケーションを異なるバージョンのアセンブリにバインドする必要がある場合は、LoadFromなどを使用せずに各アプリに適切なバージョンを使用できるように、それらのビルドに異なるアセンブリバージョンを指定することをお勧めします。
ビルドの出荷ビルドの出荷用にそのバージョンを変更することをお勧めするかどうかは、エンドユーザーに対してバインディングをどのように機能させるかによって異なります。これらのビルドを並べて配置しますか、それともインプレースにしますか？2つのビルドの間に多くの変更がありますか？彼らは何人かの顧客を壊すつもりですか？それがそれらを壊すことを気にしますか（またはユーザーにあなたの重要な更新を使用するように強制したいですか）？はいの場合は、アセンブリバージョンのインクリメントを検討する必要があります。ただし、繰り返しになりますが、これを何度も実行すると、ユーザーのディスクに古いアセンブリが散らかってしまう可能性があることを考慮してください。
アセンブリのバージョンを変更する場合ハードコーディングされたバージョンを新しいバージョンに変更するには、ヘッダーファイルのバージョンに変数を設定し、ソースのハードコーディングを変数に置き換えることをお勧めします。次に、ビルド中にプリプロセッサを実行して、正しいバージョンを配置します。変更によるバグを見つける時間が増えるように、出荷直前ではなく出荷直後にバージョンを変更することをお勧めします。
于 2008-12-28T18:14:13.103 に答える
1
ライブラリの場合、バージョン番号は2 つのリリース間の互換性のレベル、つまりアップグレードの難易度を示します。
バグ修正リリースでは、バイナリ、ソース、およびシリアライゼーションの互換性を維持する必要があります。
マイナー リリースはプロジェクトごとに意味が異なりますが、通常はソースの互換性を維持する必要はありません。
メジャー バージョン番号は、3 つの形式すべてを壊す可能性があります。
根拠についてはこちらに詳しく書いています。
于 2010-11-28T17:35:07.897 に答える