増分バージョン-開発中？またはリリース後？
主に主観的な質問だと思いますが、以下の状況に人々がどう対処するかに興味があります。プログラマースタックの交換についても同様の質問がたくさんありますが、開発の前または後にバージョン番号を提案されたリリースに更新するかどうかというこの正確な問題については触れていません（私が見つけることができました）。
私は稼働中のシステムを持っています。それをバージョンと呼びましょう1.0.x.xMajor.Minor.Build.Revision Microsoftスタイルのバージョン管理を使用しています。
顧客からいくつかの新機能のリクエストがあり、この作業パッケージは1.1.x.xリリースになると判断しました。
開発中、いつバージョン番号を更新しますか？仕事を始めたら？それとも完成したら？
2つのアプローチを見ることができますが、どちらも100％満足していません。
開発の開始時にマイナーバージョンをインクリメントします。最終的にリリースされるソフトウェアは、おそらく1 .1。5562.12589のようになります。
開発中はバージョンを1.0.xxに保ち、
testedバージョンを1 .。5562.12589のようにしてから、versionを更新する必要がある場合アセンブリ（メジャーリリースまたはマイナーリリースでは手動で行います）を1 .1。xxに厳密に記述します（コードのバージョンを厳密に言えば、アセンブリをインクリメントするために再構築する必要があったので）。番号）はテストされていません。
ここで推奨されるアプローチは何ですか？
編集：
長所と短所に関して：
オプション1。
Pros-リリースされたバージョンはすでに1.1.x.xであるため、マイナー番号は正確であり、そのビルド/リビジョンはテスト済みコードを表しています
短所-リリースされたバージョンはバージョン1.1.0.0ではなく、顧客または開発者には、バグ修正などの作業が1.1.0.0リリース後に行われたように見える場合があります。 。
オプション2。
長所-開発が完了してテストされるまで、バージョンは1.1.0.0に到達しません。つまり、安定した1.0.x.xバージョンで行われている作業と、テストされた1.1.0.0バージョンのデプロイメントとの間には、明確な論理的カットオフが存在します。
短所-テスト後、リリース前にバージョンを1.0.x.xから1.1.0.0に手動で調整する必要があります。誰かが誤って間違った場所をチェックインした場合、テストされていないコードが含まれる可能性があります。
現時点では、両方の利点と両方の欠点を見ることができるので、どちらの悪のどちらが小さいかはわかりません。誰かがバランスを傾けたり、見逃したものを見つけたりするのを手伝ってくれる人を望んでいます。
お客様が1.1.2475.54387が「1.1以降に何か変更された」という意味であるとお客様が考える場合、それを忘れてください。私の経験では、事実上すべての顧客どちらかバージョンの下位コンポーネントが何を意味するかを気にしていませんor彼らは気にしますand理解していますそれらはビルド番号およびVCリビジョンであり、定義により決して0になることはありません。
もう少し一般的：見栄えは妥当な目標ですが、ビジネスのコンテキストでは、購入を決定する人が何を考えているかだけが重要です。それらの人々はほとんど常に真っ直ぐに上のカテゴリー（a）に分類されます。手付かずのビルド番号が製品のビジネスの成功に悪影響を与えるシナリオは考えられません。
オプション1の大きな利点の1つは、ソフトウェアがすべての単体テストと新しい一連の要件に対する受け入れテストに合格するとすぐに、それを出荷できることです。
バージョン番号の増分を遅らせる場合は、出荷する正しいバージョンで別のビルドを行う必要があります。すべてを再構築したら、本当にすべてのテストを再実行する必要があります。