Within Microsoft, we use two different terms to describe versioning: breaking change & non-breaking change. I say this because many times people believe that only non-breaking changes are “versioning”. 😉 That said, both play an important role in the overall versioning story we support in Indigo.
In terms of data contract versioning (and therefore XSD — since Indigo maps the abstract notion of a data contract to a schema and back), we support both non-breaking and breaking changes — although we certainly recommend that you know what you are doing when you introduce a breaking change. An incomplete list of what is a breaking change and not follows:
Non-breaking change
Adding a new data member
Breaking change
Changing the data contract namespace or local name
Mutating a data member’s attributes in a incompatible way (we haven’t revealed some of these features so I am not going to talk about this)
Removing a data member (there is a case where this is not a breaking change — but I can’t go into it)
The key takeaway from the above is that data contracts are mutable. You may change them without breaking existing services and clients — assuming that you only make non-breaking changes. You may also change them in such a way that existing services and clients fail to work with the mutated contract. One great way of doing this is to change the namespace of the data contract.
