On 10/16/2011 11:29 PM, Scott Carey wrote:
> If you want the server side to evolve you can:
> add new fields
> remove fields (only if the field has a default on the client side)
> promote fields as permitted (int -> long; string -> nullable string; etc.)
> rename fields or other named types with aliases.

Should we add this summary to the documentation somewhere?  Perhaps the
specification?

The other item to note is that you can add new messages to protocols but
shouldn't remove them or change their semantics incompatibly, and that
message parameters should be treated like fields above.

Doug

Reply via email to