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

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

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

「リリース」する最初のバージョンが何らかの形で不完全であることがわかっている場合を除き、バージョン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に変更します（いくつかのバグを修正しました）。

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

私はx.y.z一種のバージョン管理を使います

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

私は基本的にこのパターンに従います：

• 0.1.0から開始

• 準備ができたら、ソースリポジトリのコードを分岐し、0.1.0タグを付けて0.1.0分岐を作成します。ヘッド/トランクは0.2.0-スナップショットまたは類似のものになります

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

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

• それから-誰がメジャーバージョンをいつ増やすかを決めることができます...

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

xyz

どこ：

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

例：

• 新しいアプリケーションの場合、バージョン番号は1.0.0から始まります。
• 新しいバージョンにバグ修正のみが含まれている場合は、修正プログラム番号を増やして、バージョン番号が1.0.1になるようにします。
• 新しいバージョンにバグ修正の有無にかかわらず新機能が含まれている場合は、機能番号を増やし、修正プログラム番号をゼロにリセットして、バージョン番号が1.1.0になるようにします。機能番号が9に達した場合、メインバージョン番号を増やし、機能と修正プログラム番号をゼロにリセットします（2.0.0など）

ここでabcdを使用します

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

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

Eclipseでは、バージョン番号は4つのセグメントで構成されます。3つの整数とそれぞれと名付けられた文字列ですmajor.minor.service.qualifier。各セグメントは異なる目的を捕捉します：

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

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

初見はリリース日についての印象を与えるので、それはかなり有益です。ただし、製品のライフサイクルにおける正確なポイントを常に知りたいので、私はxyzスキームを好みます（Major.minor.release）

基本的な答えは「場合によります」です。

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

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

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

マヘシュが言うように：私はxyz種類のバージョン管理を使用します

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

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

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

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

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

次のようなabcアプローチに従います。

アプリケーションでいくつかの大きな変更が発生した場合は、「a」と表示されます。.NET 1.1アプリケーションを.NET 3.5にアップグレードするように

新しいCRや拡張機能が実装されているなど、いくつかのマイナーな変更がある場合は、「b」が無効です。

コードにいくつかの欠陥の修正がある場合は、「c」が不適切です。

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

あなたが私のような人なら、あなたはそれをあなたのソフトウェアの進歩のペースに一致するように方法のハイブリッドにするでしょう。

特にQA /コンプライアンスが混在している場合は、最も受け入れられているパターンはabcまたはabcdだと思います。私は主流のためにそれをあきらめたバージョンの通常の部分である日付の周りにたくさんのたわごとを持っていました。

私はビルドを追跡しないので、ホットフィックスが関係していない限り、abcパターンを使用したいです。修正プログラムを適用する必要がある場合は、時間付きの日付としてパラメーターdを適用します。時間パラメーターをdとして採用したのは、実際に生産が爆発する1日にいくつかの潜在的な可能性があるためです。プロダクション修正のために発散しているときのみ、dセグメント（YYYYMMDDHHNN）を適用します。

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

それがすべて言った。あなただけのことができる場合ツール暗礁のconfigureにするとして実行し、それはマーシャルにバージョニングの意見ファセットを持つ頭痛からあなたを維持し、開発プロセスの誰もが一般的であるので、あなただけ...「ツールを使用する」と言うことができますので、対応。