私はソフトウェアをオンラインで配布していますが、バージョン番号をより適切に定義する適切な方法があるかどうか常に疑問に思っています。
答えにABCDがあるとしましょう。各コンポーネントをいつ増やしますか?
D mod 2 == 1 など、他のバージョン番号のトリックを使用していますか?これは、社内リリースのみであることを意味しますか?
独自のバージョン番号を持つベータ リリースはありますか、それともバージョン番号ごとのベータ リリースはありますか?
12209 次
15 に答える
29
一部のアプリ (Perforce など) で使用される Year.Release[.Build] 規則が気に入り始めています。基本的には、リリースした年と、その年内のシーケンスを示しているだけです。したがって、2008.1 が最初のバージョンになり、1 ～ 3 か月後に別のバージョンをリリースすると、2008.2 になります。
このスキームの利点は、メジャー バージョンのインクリメントを保証するのに十分なほどメジャーな機能であるかどうかについての議論に入る、リリースの暗黙の「規模」がないことです。
オプションのエクストラは、ビルド番号にタグを付けることですが、それは内部目的のみである傾向があります (たとえば、EXE/DLL に追加されるため、ファイルを調べて正しいビルドがそこにあることを確認できます)。
于 2008-09-25T17:27:48.263 に答える
8
私の意見では、ほとんどすべてのリリース番号スキームを多かれ少なかれ正常に機能させることができます。私が取り組んでいるシステムは、11.50.UC3などのバージョン番号を使用しています。Uは32ビットUnixを示し、C3はマイナーリビジョン（フィックスパック）番号です。他の文字は、他のプラットフォームタイプに使用されます。（このスキームはお勧めしませんが、機能します。）
これまでに述べられていないが、人々が議論したことに暗黙のうちにあるいくつかの黄金のルールがあります。
- 同じバージョンを2回リリースしないでください。バージョン1.0.0が誰にでもリリースされると、再リリースすることはできません。
- リリース数は単調に増加するはずです。つまり、バージョン1.0.1、1.1.0、または2.0.0のコードは、常にバージョン1.0.0、1.0.9、または1.4.3よりも後のバージョンである必要があります。
現在、実際には、新しいバージョンが利用可能である間、人々は古いバージョンの修正をリリースする必要があります。たとえば、GCCを参照してください。
- GCC 3.4.6は4.0.0、4.1.0（およびAFAICR 4.2.0）の後にリリースされましたが、GCC 4.xに追加された追加機能を追加するのではなく、GCC3.4.xの機能を継続します。
したがって、バージョン番号付けスキームを慎重に構築する必要があります。
私がしっかりと信じているもう1つのポイント：
- リリースバージョン番号は、些細なプログラムを除いて、CM（VCS）システムのバージョン番号とは関係ありません。複数のメインソースファイルを含む深刻なソフトウェアには、単一のファイルのバージョンとは関係のないバージョン番号が付けられます。
SVNを使用すると、SVNのバージョン番号を使用できますが、予想外に変更されるため、おそらく使用されません。
私が扱っているものについては、バージョン番号は純粋に政治的な決定です。
ちなみに、バージョン1.00から9.53までのリリースを経たソフトウェアを知っていますが、その後2.80に変更されました。それは重大な間違いでした-マーケティングによって決定されました。確かに、ソフトウェアのバージョン4.xは廃止された/廃止されたため、すぐに混乱することはありませんでしたが、ソフトウェアのバージョン5.xはまだ使用および販売されており、リビジョンはすでに3.50に達しています。避けられない競合が発生したときに、5.x（古いスタイル）と5.x（新しいスタイル）の両方で動作する必要があるコードがどうなるかについて、私は非常に心配しています。古い5.xが本当に死ぬまで、5.xに変更することで、彼らが愚痴をこぼしてくれることを期待しなければならないと思いますが、私は楽観的ではありません。また、3.60などの人工的なバージョン番号を使用して3.50コードを表し、次のことを行う必要がif VERSION > 900なく、適切なテストを実行できるようにします。if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400)、バージョン9.00 x 900を表します。次に、バージョン3.00.xC3で導入された重要な変更があります。私のスキームでは、マイナーリリースレベルでの変更を検出できません... grumble ... grumble ...
注意：Eric Raymondは、リリースの命名（番号付け）に関する（リンクされた）セクションを含むソフトウェアリリースプラクティスHOWTOを提供しています。
于 2008-09-28T04:50:45.070 に答える
7
私は通常、D をビルド カウンターとして使用します (コンパイラによる自動インクリメント)。ビルドが「パブリック」にリリースされるたびに C をインクリメントします (すべてのビルドがリリースされるわけではありません) A と B はメジャー/マイナー バージョン番号として使用され、手動で変更されます。
于 2008-09-25T17:04:49.193 に答える
5
この質問に答えるには 2 つの方法があると思いますが、それらは完全に補完的なものではありません。
- 技術: 技術的なタスクに基づいてバージョンを増やします。例: D はビルド番号、C はイテレーション、B はマイナー リリース、A はメジャー リリースです。マイナー リリースとメジャー リリースの定義は非常に主観的ですが、基盤となるアーキテクチャの変更などに関連する可能性があります。
- マーケティング: 顧客に提供される「新しい」機能または「役立つ」機能の数に基づいてバージョンを増やします。バージョン番号を更新ポリシーに関連付けることもできます... A への変更では、ユーザーはアップグレード ライセンスを購入する必要がありますが、他の変更では必要ありません。
肝心なのは、あなたとあなたの顧客にとって機能するモデルを見つけることだと思います. 偶数バージョンがパブリック リリースで、奇数バージョンがベータまたは開発リリースと見なされるケースをいくつか見てきました。C と D を一緒に無視する製品を見たことがあります。
次に、Microsoft の例があります。.Net Framework のバージョン番号に対する唯一の合理的な説明は、マーケティングが関与したということです。
于 2008-09-25T17:09:49.070 に答える
4
私たちのポリシー:
- A - 機能またはインターフェイスの大幅な (> 25%) 変更または追加。
- B - 機能またはインターフェースの小さな変更または追加。
- C - インターフェイスを壊すマイナーな変更。
- D - インターフェイスを変更しないビルドの修正。
于 2008-09-25T17:02:28.527 に答える
2
私がこれまでにバージョン番号を使用したのは、顧客がバージョン 2.5.1.0 などを使用していることを知らせるためだけでした。
私の唯一のルールは、その番号を報告する際の間違いを最小限に抑えるように設計されて います。4 つの番号はすべて 1 桁のみにする必要があります。
1.1.2.3
大丈夫ですが、
1.0.1.23
ではありません。顧客は、両方の番号を (少なくとも口頭で) 「1-1-2-3」と報告する可能性があります。
ビルド番号を自動インクリメントすると、多くの場合、次のようなバージョン番号になります
1.0.1.12537
これもあまり役に立ちません。
于 2008-09-25T17:17:37.213 に答える
2
優れた非技術的なスキームでは、ビルド日付を次の形式で使用します。
YYYY.MM.DD.ビルド番号
BuildNumber は、連続する番号 (変更リスト) であるか、毎日 1 から始まります。
例: 2008.03.24.1 または 2008.03.24.14503
これは主に内部リリース用です。公開リリースでは、月に 1 回以上リリースしない場合、2008.03 として印刷されたバージョンが表示されます。メンテナンス リリースには、2008.03a、2008.03b などのフラグが付けられます。「c」を超えることはめったにありませんが、それが良い指標である場合は、より良い QA および/またはテスト手順が必要です。
ユーザーによく見られるバージョン フィールドは、使いやすい「2008 年 3 月」形式で出力し、[バージョン情報] ダイアログまたはログ ファイルでより多くの技術情報を予約する必要があります。
最大の欠点: 同じコードを別の日にコンパイルすると、バージョン番号が変わる可能性があります。ただし、バージョン管理の変更リストを最後の番号として使用し、それと照合して日付も変更する必要があるかどうかを判断することで、これを回避できます。
于 2008-09-25T21:16:46.107 に答える
2
人々は、これを必要以上に難しくしようとする傾向があります。製品に存続期間の長いブランチが 1 つしかない場合は、ビルド番号で連続するバージョンに名前を付けます。「マイナーなバグ修正は無料ですが、メジャーな新しいバージョンには料金を支払う必要があります」というような場合は、1.0、1.1 ... 1.n、2.0、2.1... などを使用してください。
例の A、B、C、および D が何であるかをすぐに理解できない場合は、明らかにそれらは必要ありません。
于 2008-09-25T17:03:04.203 に答える
1
ライブラリの場合、バージョン番号は2 つのリリース間の互換性のレベル、つまりアップグレードの難易度を示します。
バグ修正リリースでは、バイナリ、ソース、およびシリアライゼーションの互換性を維持する必要があります。
マイナー リリースはプロジェクトごとに意味が異なりますが、通常はソースの互換性を維持する必要はありません。
メジャー バージョン番号は、3 つの形式すべてを壊す可能性があります。
根拠についてはこちらに詳しく書いています。
于 2010-11-28T17:41:59.457 に答える
1
年月日が好きです。したがって、v2009.6.8 がこの投稿の「バージョン」になります。（合理的に）複製することは不可能であり、何かが新しいリリースであることは非常に明確です。小数を削除して v20090608 にすることもできます。
于 2009-06-08T20:19:56.943 に答える
1
2.5.1などのVRMを使用しています
V (バージョン) の変更は大幅な書き直しです
。R (リビジョン) の変更は重要な新機能またはバグ修正です
。M (モディフィケーション) の変更はマイナーなバグ修正 (タイプミスなど) です。
最後に SVN コミット番号を使用することもあります。
于 2008-09-25T17:00:38.330 に答える
1
結局のところ、それはすべて本当に主観的なものであり、単にあなた自身/あなたのチーム次第です.
すでにすべての回答を見てください-すべて非常に異なります。
個人的に私が使用するMajor.Minor.*.*のは、Visual Studio がリビジョン/ビルド番号を自動的に入力する場所です。これは私の職場でも使われています。
于 2009-05-30T10:08:28.167 に答える
0
自社開発の場合、以下のフォーマットを使用します。
[Program #] . [Year] . [Month] . [Release # of this app within the month]
たとえば、今日アプリケーション # 15 をリリースし、それが今月 3 回目の更新である場合、私のバージョン # は
15.2008.9.3
これはまったく標準的ではありませんが、私たちにとっては便利です。
于 2008-09-25T17:25:21.657 に答える
0
過去 6 つのメジャー バージョンでは、M.0.mb を使用しました。M はメジャー バージョン、m はマイナー バージョン、b はビルド番号です。そのため、リリースされたバージョンには、6.0.2、7.0.1、...、最大 11.0.0 が含まれていました。2 番目の数値が常に 0 である理由を尋ねないでください。何度も質問したのですが、本当のところは誰にもわかりません。1996 年に 5.5 がリリースされて以来、ゼロ以外はありません。
于 2008-09-25T17:25:40.703 に答える