.net - プロジェクトをどのようにバージョン管理しますか？

Question

Microsoftが自社製品のバージョン管理時にこのテンプレートMajor.Minor.Build.Revisionを使用していることを理解しています。

「開発者」がソフトウェアに大きな変更があり、下位互換性を想定できないことを示したい場合は、メジャーが変更されます。たぶん、コードの大幅な書き直しが行われています。

マイナー番号は、下位互換性を目的とした大幅な機能強化を表しています。

ビルド番号は小さな変更です。たとえば、同じソースの再コンパイルです。

リビジョンはセキュリティホールを修正するために使用され、完全に交換可能である必要があります。ビルドとリビジョンはどちらもオプションです。この情報は、 MSDNバージョンクラスに基づいています。

プロジェクトをどのようにバージョン管理し、なぜこの方法でバージョン管理するのですか？

score 7 · Accepted Answer

私は通常、私が働いている場所でmajor.minor [.maintenance [.build]]を実行しますが、プロジェクトごとに少し異なるようです。

あなたが言ったのと同じメジャー/マイナー。小さな（バグ）修正のためにメンテナンスが増分され、ビルドサーバーが実行されるたびにビルドされます。

score 4 · Accepted Answer

私は個人的に、プロジェクト/製品のユーザーが期待できる下位互換性のレベルに焦点を当てたスキームを使用するのが好きです:

1.0 より前:

0.0.1 = 最初のリリース
0.-.X = 下位互換性のある更新
0.X.0 = 下位互換性のない更新

1.0以降:

-.-.X = インターフェイスを変更せずに更新
-.X.0 = 下位互換性のあるインターフェイスの追加による更新
X.0.0 = 下位互換性のないアップデート

バージョン番号の中心点として互換性を使用すると、ユーザーは、特に製品がライブラリの場合、スムーズで安全なアップグレードが期待できるかどうかを判断しやすくなります。

score 2 · Accepted Answer

Xyzをよく目にします。ここで、Xはリリース番号の翌年、yzはその年の月です。つまり、201はリリースから2年後の1月です。つまり、5月に製品が発売されたとき、最初のリリース番号は105です。来年の2月のリリースは202です。

score 2 · Accepted Answer

通常、プロジェクトは現在のリリース日YYYY.MM.DD. *に基づいてバージョン管理され、ビルド番号は自動的に生成されるため、たとえば、今日リリースされた場合は2008.9.26.BUILDになります。

score 1 · Accepted Answer

major.minor.point.revisionを使用します。ここで、pointはバグ修正のみのリリースであり、revisionはリポジトリのリビジョンです。それは簡単でうまく機能します。

score 1 · Accepted Answer

私はMajor.minorを実行します。私は（時折助けを借りて）単一の開発者であるため、ほとんどの人は私が行ったマイナーな修正についてあまり気にすることができませんでした。そのため、変更やアップグレードを行うときに、新しい機能とメジャーバージョン番号を追加するときに、マイナーバージョンを繰り返し処理します。それ以外の場合は、バージョン番号に関する限り、小さな修正を無視します（ただし、自分で参照する必要がある場合は、Subversionのリビジョン番号があります）。

score 1 · Accepted Answer

私は多くの小さなプロジェクトに取り組んでいますが、個人的にはこれが便利だと感じています。

PatchNumber.DateMonthYear

これは、ユーザーが最後の更新の日時と更新の頻度を確認できる小さなWebベースのツール用です。

PatchNumberは実行されたリリースの数であり、残りはこれが公開されたときにユーザーに表示するために使用されます。

score 1 · Accepted Answer

Major.Minor.BugFix.SVNRevision

例: 3.5.2.31578

SVN リビジョンは、顧客に送信されたコードの非常に正確な平和を提供します。そのバグ修正があったかどうかは絶対にわかります。
また、アプリケーションエラーが発生した場合に適切な PDB を見つけるのにも役立ちます。ビルドサーバーの SVN リビジョンを一致させ、PDB を EXE の場所にコピーし、デバッガーを開くと、クラッシュスタックトレースが取得されます。

score 1 · Accepted Answer

patch がホットフィックスまたはパッチリリースである Major.minor.patch.build。

SVN で QA を取得できる場合は、ビルド番号として svn HEAD リビジョンを使用できます。このように、各ビルドは、ソース管理とビルドの内容に関して、それがどこから来たのかを説明します。これは、ギャップ (1.0.0.1、1.0.0.34....) を伴うビルドがあることを意味します。

score 0 · Accepted Answer

私は、80 年代に Nantucket の Clipper コンパイラのバージョン管理方法が好きでした。

クリッパーウィンター 1984
クリッパーサマー 1985
クリッパーウィンター 1985
クリッパーオータム 1986
クリッパーサマー 1987

ああ、オーバーレイ....

【涙目になる】

score 0 · Accepted Answer

番号を持っているだけです。最初のリリースは001. 2 番目のリリースの 3 番目のベータ版は002b3などです。これはあくまで個人的なもので、現時点で「リリース」されたものは何もないので、これはすべて理論上の話です。

score 0 · Accepted Answer

Ubuntu と似た形式のY.MMDDを使い始めました。

これは、いくつかの理由で役立ちます。

バージョン要件を確認する方が簡単です: if (version < 8.0901) die/exit/etc. ;
ビルドプロセスで自動生成できます

その2番目のポイント（ルビーとレーキ）：

def serial(t)
   t = Time.now.utc if not t.instance_of?(Time)
   t.strftime("%Y").to_i - 2000 + t.strftime("0.%m%d").to_f
end

serial(Time.now)     #=> 8.0926
serial(Time.now.utc) #=> 8.0927

注: t.strftime("%Y.%m%d").to_f - 2000 では浮動小数点の不正確さが発生します: 8.09269999999992

.net - プロジェクトをどのようにバージョン管理しますか？

12 に答える 12

Related

Reference