Motivation
When a service-consumer starts using a service, a dependency to that service's contract is created. The service's contract can't undergo any major changes without this having an impact on the service-consumer. This introduces the need for several versions of a service.
Argumentation
Services evolve over time. Service consumers need to know how the services evolve to be able to evolve alongside the service-lifecycle. The versioning life-cycle need to be predictable for the service-consumers, so that they can plan ahead for new versions of a service. Therefore any service must have a documented versioning strategy, so that consumers can plan their update strategy in accordance.
The versioning strategy and policies should be a part of a service's Service Level Agreement. See: P32. A service shall document its Service Level Agreement SLA (response time=30ms, availability=99.995%)
Exceptions/special cases
In most real cases, this policy will be limiting to a small set of versioning strategies (multiple endpoints, evolving service adaptor, adaptors, forced big-bang (really the worst versioning strategy..) et all..).
Definitions
Status
PAB discussions
Design-Time Governance - SOA Design Rules FAQ
- [Question still to be asked..]