あなたのアプリケーションに、人々が開発する公開 API がある場合、次のシナリオで何をしますか?
アプリケーションのサービス パックを公開する場合、アセンブリのバージョン番号を変更しますか?
同様に、ホット フィックスを提供する場合、バージョン番号を変更しますか?
提供する場合、アセンブリ リダイレクト用のポリシー ファイルを提供しますか? または、ポリシー ファイルがシナリオのどこに適合するかがわからない場合は、バージョン番号を変更しない、またはポリシー ファイルを提供してバージョンを変更しないことを選択するのはどのような場合ですか?
We keep to the rule that the first three parts of the version number are more or less artificial numbers generated by marketing. The pattern is something like "Major.Minor.ServicePack". (The difference between a service pack and a hot fix is just politcs.) But the last number is auto inserted by the build script and keeps the last changed subverion revision of the branch the script is running on. By this we can always find the exact code base for any binary file "out in the wild".
パブリック API のメソッドなどが変更された場合、または API を使用するコードの一部をクライアントが書き直す必要があるように呼び出しの動作が変更された場合にのみ、バージョン番号を上げる必要があります。
バージョン番号を変更しない理由は、厳密な名前のアセンブリに関連しています。
既にコンパイルされたアプリケーションが更新された厳密な名前のアセンブリを使用できるようにする場合は、アプリケーションがコンパイルされたのと同じバージョンのアセンブリを必要とするため、バージョン番号を変更しないでください。
もちろん、これはアセンブリのインターフェイスが変更されていない場合にのみ当てはまります。
Microsoft の方法は、Major.Minor.BuildNumber.Revisionを使用することです。サービス パックとホット フィックスの BuildNumber.Revision を自動的に生成して使用することをお勧めします。API の拡張用にマイナー ビルド番号を手動で変更して使用します。下位互換性のない方法で物事を変更したり、機能に大幅な (30% 以上の) 変更や拡張を導入したりする場合は、メジャー ビルド番号を手動で変更して使用します。
Jeff Atwood は、実際にバージョン番号付けについて石器時代にさかのぼるブログ投稿を持っています。バージョン番号の自動インクリメントに関する質問がここにあり、 Build Version Increment Add-In Visual Studio にリンクされている回答が気に入っています。