This article on TheServerSide.NET is an interesting analysis on versioning issues of SOA solutions:

A SOA Versioning Covenant

When it comes to distributed systems, versioning is always the Achilles Heel… One goal of service-oriented (SO) design is to help address the versioning issue by ensuring that every service and client of a service is an autonomous, independent entity. However, that’s only part of the story. What makes this even more interesting is that in an SO world versioning is merely a subset of a bigger issue. That issue is the fluid nature of the agreements (contracts) established between software entities. I may create a PostOrder service that accepts various different types of request, but always performs the same action. Then, I might version some of those request types. But versioning merely means that I have increased the number of overall request types – there’s really no difference between a new version of a request and a brand new request. Before I go any further, a quick disclaimer. In this entry I am talking specifically about SO design. I am not talking about n-tier or client/server design. They are totally different from SO. In an n-tier model, we’re talking about an application that is designed as a set of interrelated logical layers. Those layers are then potentially deployed on different tiers (different processes or different machines). The fact that some layers of an application are physically separated from each other doesn’t change the reality that these are just logical layers of a single autonomous entity. In this article I am discussing solutions to some serious issues in the SO world. In most cases these solutions do not apply to the n-tier world, where good solutions already exist.

(local copy here in PDF format)