いまTsugumiをやっている(本当は何もやれてない)ので、平行してバージョン管理をどうするかを考えています。
たとえばASP.Netの場合にはすべて自分の管理するサーバ内の整合性を保つようにすればOKで、テーブルのバージョンアップと、ソフトのバージョンアップを同期をとって行えれば十分です。
もちろんソフトだけのバージョンアップが大半でDBは少ないことでしょう。
今回やろうとしているDB - XMLWebサービス - ノータッチデプロイメントの場合にはさまざまな管理を行う必要があります。
まずノータッチデプロイメントの場合常に最新バージョンのソフトが利用されると考えられますが、クライアントにコピーされた場合にはどうでしょう？
ノータッチデプロイメントかどうかを調べればいいというわけではありません。
クライアントにコピーされた古いバージョンを自分のHTTPサーバに置かれてノータッチデプロイメントされた場合にはどうなるでしょう。(XMLWebサービスが呼び出されなくなるはずですが、抜け道は存在します。)
他に一般の配布を行われるクライアントを作る可能性もあります。
以上のようなことを考えるとXMLWebサービスの適切なバージョン管理が必要になります。
一般的にI/Fが変わった場合にクライアントプログラムはWSDLによる再生成を迫られますし、そういった意味合いでも1つのasmxを公開した場合i/fが変わらない間は同じasmxを修正し、i/fが追加になるような修正を行うときに別asmxを作ってはどうかと思うのです。
そうなると、asmxはバージョン単位Tsugumi1.asmxなどというファイル名にするほうがよいのではないでしょうか。
さて、Version1とVersion2の変更箇所が新しい機能だったとします。(ユーザ管理機能が増えるとか)
その場合Version1とVersion2のログイン機能は互換性があるともいえます。
この場合クライアントプログラムはVersion2に乗り換えるべきでしょうか？
実際問題としては必要はありません。ただし必要が無いからといってVersion1をそのまま放置すると、Version2に乗り換えるタイミングをなくし、まったく同一のプログラムを維持することになってしまいます。
また自分ではない誰かがI/Fを利用して開発している場合その開発者に古いバージョンであることを通知するよい方法がなかなか見つかりません。
すべてのXMLWebサービスにこういったインタフェースをつけるべきではないのでしょうか？
string GetNewVersionURI() //最新バージョンが存在している場合のURI、自分であれば自分のURI
bool GetCompatible() //このバージョンが正常に動作するバージョンであるかどうか
GetCompatible()でfalseが帰ってくる場合にはNotImplementsでExceptionを投げることにする。SOAPExceptionでは正確な理由が判明しないため理由は事前に抑えておく。
いかがでしょう？
RFC!!