共通のビジネスコード、WCFサービス、単一のデータベースを共有する複数のクライアントUI（デスクトップ、Silverlight、iPhone）で構成される製品があるとします。すべてのソースは単一のgitリポジトリにあります。クライアントアプリケーションとサービスのバージョン番号が分かれていますか？
各UI部分とWCFサービスを個別にビルドしてバージョン管理する必要がありますか、または新しいビルドですべてのバージョン番号を増やす必要がありますか？
私の頭の上には、これを処理するさまざまな方法がありますが、どれも「正しい」ものではありません。それはすべてあなたのリリースプロセスと、あなたの製品を顧客に提示する方法に依存します。
ロックステップでコンポーネントをテストしてリリースする場合、バージョン番号をロックステップでも移動させると便利です。そうすれば、デスクトップUIのバージョン1.4.4は1.4.4のiPhoneバージョンが同じ機能を持つべきであるということを誰もが知っています。
異なる時期に異なる機能を持つことができる（デスクトップの機能をリリースするのは急いでいるが、iPhoneを待つことができる）場合は、明らかに異なるバージョン番号を使用します。しかし、メジャーリリースではバージョン番号をX.0.0に再同期することをお勧めします。
製品を通常の<major>.<minor>.<maintenance-patch>部品の独自のバージョンスケジュールに従わせて、最後のコンポーネントとしてビルド番号を含めることで、やや気にすることができます。だから、<major>.<minor>.<patch>.<build>になります。このアプローチの利点は、異なる時期に異なるコンポーネントをリリースできることです。それでも、元のビルドのレコードを取得できます。この場合、ビルド番号は単調に増加する番号である必要があります。通常は、集中ビルドシステムによって管理されます。私は通常、ビルドシステムにバージョン番号の制御を残すのは好きではありません。ビルド番号を持つことは、マーケティングや製品ライン管理などで、バージョン番号の重要な部分。
私がお勧めするものの1つは、ビルドプロセスで一度に「世界を構築する」ことです。明らかに、開発者の便宜のために別々のUIを構築できるようにしたいと考えていますが、すべての依存関係を含む可能なすべてのコンポーネントをワンショットで構築する夜間の1回のプロセスを管理する方がはるかに簡単です。また、すべてのUIがリポジトリ内の同じ現在の共有コンポーネントを使用していることを確認してください。異なるバージョンの共有コンポーネントが必要な場合は、すべてを正しく構築しようとすると怪我をすることがあります。その後、UIのビルドをトリガするさまざまなコンポーネント用に別々のビルドを作成します。