web-dev-qa-db-ja.com

ベストプラクティス：ソフトウェアのバージョン管理

暇なときに開発するソフトウェアをバージョンアップするためのガイドラインや標準的なベストプラクティスはありますか？そのようなソフトウェアをバージョン管理する必要があると思うので、バージョン1について話している（たとえば、バグ修正、サポートなど）。

しかし、どこでバージョン管理を開始しますか？ 0.0.0？または0.0？そして、どのように数字を増やすのですか？メジャーリリース。マイナーチェンジ？バージョン管理システムへのコミットは別のバージョンではありませんか？または、これは生産的な方法で使用されるバージョンにのみありますか？

versioning
212
RoflcoptrException

「リリース」する最初のバージョンが何らかの形で不完全であることがわかっていない限り、バージョン1から開始する必要があります。

バージョンを増やす方法については、あなた次第ですが、メジャー、マイナー、ビルド番号をガイドとして使用してください。

すべてのバージョンを別のバージョンとしてソース管理にコミットする必要はありません-すぐに非常に大きなバージョン番号が得られます。新しいバージョンを外部にリリースするときにのみ、バージョン番号を（何らかの方法で）増やす必要があります。

そのため、バージョン1.0.0.0からバージョン2.0.0.0に大きな変更を加える場合（たとえば、WinFormsからWPFに変更した場合）。小さな変更を加える場合は、1.0.0.0から1.1.0.0に移動します（PNGファイルのサポートを追加しました）。マイナーな変更を行う場合は、1.0.0.0から1.0.1.0に移動します（いくつかのバグを修正しました）。

本当に詳細を取得したい場合は、チェックイン/コミットごとに増分するビルド番号として最終番号を使用します（しかし、それは行き過ぎだと思います）。

125
ChrisF

x.y.z種類のバージョン管理を使用します

x-メジャーリリース
y-マイナーリリース
z-ビルド番号

63
Mahesh Velaga

基本的にこのパターンに従います。

  • 0.1.0から開始

  • 準備ができたら、ソースリポジトリでコードをブランチし、タグ0.1.0を作成し、0.1.0ブランチを作成します。ヘッド/トランクは0.2.0-snapshotまたは同様のものになります。

  • トランクのみに新しい機能を追加しますが、ブランチに修正をバックポートし、そのうちリリース0.1.1、0.1.2、...

  • 製品が機能完了と見なされ、大きな欠点がない場合、バージョン1.0.0を宣言します

  • それ以降-誰もがメジャーバージョンをインクリメントするタイミングを決定できます...

42
Bozhidar Batsov

私は自分のアプリケーションにこのルールを使用します。

x.y.z

どこで：

  • x =メインバージョン番号、1-〜。
  • y =機能番号、0〜9。変更にバグ修正の有無にかかわらず新しい機能が含まれる場合は、この数を増やします。
  • z =ホットフィックス番号、0-〜。変更にバグ修正のみが含まれる場合は、この数を増やします。

例：

  • 新しいアプリケーションの場合、バージョン番号は1.0.0で始まります。
  • 新しいバージョンにバグ修正のみが含まれる場合は、ホットフィックス番号を増やして、バージョン番号が1.0.1になるようにします。
  • 新しいバージョンにバグ修正付きまたはバグ修正なしの新機能が含まれている場合は、機能番号を増やし、修正プログラム番号をゼロにリセットして、バージョン番号が1.1.0になるようにします。機能番号が9に達した場合、メインバージョン番号を増やし、機能とホットフィックス番号をゼロにリセットします（2.0.0など）
35
Lorensius W. L. T

A.b.c.dを使用します

  • a-メジャー（クライアントへの配信時に増分）
  • b-マイナー（クライアントへの配信時に増分）
  • c-リビジョン（内部リリースで増分）
  • d-ビルド（クルーズコントロールにより増加）
11
Naeem Sarfraz

日付バージョン管理スキーム もあります。例：YYYY.MM、YY.MM、YYYYMMDD

最初の外観がリリース日について印象を与えるため、非常に有益です。しかし、ライフサイクル（Major.minor.release）で製品の正確なポイントを常に知りたいため、x.y.zスキームを好みます。

5
athspk

A.B.Cアプローチのさらに別の例は、 Eclipse Bundle Versioning です。 Eclipseバンドルには、4番目のセグメントがあります：

Eclipseでは、バージョン番号は4つのセグメントで構成されます。3つの整数とそれぞれmajor.minor.service.qualifierという名前の文字列です。各セグメントは異なるインテントをキャプチャします：

  • 主要なセグメントは、APIの破損を示しています
  • マイナーセグメントは「外部から見える」変更を示します
  • サービスセグメントはバグ修正と開発ストリームの変更を示します
  • 修飾子セグメントは特定のビルドを示します
5
cuh

以下のようなa.b.cアプローチに従います。

アプリケーションで大きな変更が発生した場合は、「a」になります。 .NET 1.1アプリケーションを.NET 3.5にアップグレードするように

新しいCRや拡張機能が実装されているなどの小さな変更がある場合は、「b」が発生します。

コードにいくつかの欠陥修正がある場合は、「c」が発生します。

2
Amandeep Kirar

基本的な答えは「それは依存します」です。

バージョン管理の目的は何ですか？多くの人はversion.revision.buildを使用し、それがdevバージョンではなくリリースバージョンであるため、version.revisionのみを世界にアドバタイズします。チェックイン「バージョン」を使用すると、バージョン番号が大きくなることがすぐにわかります。

プロジェクトを計画している場合、マイナーな変更があるリリースではリビジョンを増やし、メジャーな変更、バグ修正、機能/機能があるリリースではバージョンを増やします。ベータ版またはナイトリービルドタイプのリリースを提供している場合は、ビルドを含めるようにバージョニングを拡張し、リリースごとにそれを増やします。

それでも、結局のところ、それはあなた次第であり、あなたにとって意味のあるものでなければなりません。

2
Lazarus

Maheshが言うように：x.y.zのバージョン管理を使用します

x-メジャーリリースy-マイナーリリースz-ビルド番号

おそらくzの代わりに、日時を追加することができます。

別のリリースがある場合、マイナーリリースを増やします。メジャーリリースはおそらく0または1のままになります。実際に大きな変更を加えた場合は変更します（多くの場合、ソフトウェアが以前のリリースと下位互換性のない時点にあるか、フレームワーク全体を変更した場合）。

2
SirLenz0rlot

他の人が何をしているかをいつでも確認できることを知っています。オープンソースソフトウェアは、リポジトリへのアクセスを許可する傾向があります。たとえば、SVNブラウザーで http://svn.doctrine-project.org を指定し、実際のプロジェクトで使用されているバージョン管理システムを確認できます。

バージョン番号、タグ、すべて揃っています。

2
Manos Dilaverakis

最低の（修正プログラム以外の）セグメントでバージョン管理を開始します。このセグメントを10に制限しません。ビルドを追跡しているのでなければ、増分を適用するwhenを決定するだけです。 QAフェーズがある場合、最下位セグメントに増分を適用し、次にQAを通過してリリースされるときに次のセグメントを適用する場合があります。主要な動作/ UIの変更のために最上部のセグメントを残します。

あなたが私のような人なら、ソフトウェアの進行のペースに合わせて、それをメソッドのハイブリッドにしてください。

最も受け入れられているパターンはa.b.cだと思います。またはa.b.c.d特にミックスにQA /コンプライアンスがある場合。私は主流のためにそれをあきらめたバージョンの通常の部分である日付の周りに非常に多くの欠陥があった。

ビルドを追跡しないので、修正プログラムが関与しない限りa.b.cパターンを使用したいと思います。修正プログラムを適用する必要がある場合は、パラメーターdを時間付きの日付として適用します。時間パラメーターをdとして採用したのは、実稼働で物事が本当に爆発する1日にいくつかの可能性が常にあるためです。実動修正のために分岐している場合にのみ、dセグメント（YYYYMMDDHHNN）を適用します。

個人的には、cがYYYYMMDDHHMMまたはYYYYMMDDであるva.b revcのソフトウェアスキームに反対しません。

言ったことすべて。 snag a tool を設定して実行できる場合は、バージョン管理の意見の側面を整理する頭痛から解放され、「ツールを使用する」と言うことができます...開発プロセスは通常soに準拠しています。

0
rwheadon