The article is talking about direct source dependencies, not service dependencies. Services have to be backwards compatible or provide a migration period (of co

The article is talking about direct source dependencies, not service dependencies. Services have to be backwards compatible or provide a migration period (of course, there's no real alternative). Sort of similar to your /v2/. If you as a service provider really want to support N versions of your service, you could in theory have multiple instances of your service on different versions. Sounds like an ops and usability nightmare to me though. Clients must be rebuilt every few months so services do not have to support old clients indefinitely, so as a service provider you can rely on a reasonably well constrained migration period.