Can I ask a monorepo question: what do you when you’re trying to upgrade dependency XYZ, and a moderate or large refactor is required in another team’s code?
If the change is small or can be automated (i.e. changing # of parameters or function names), we run a script to make the change over the entire monorepo. This enormous CL is then approved by one of the Global owners.
If the change is complex (or non-obvious), you generally introduce the new API in one CL, change each use manually (say one CL per team), and then remove the old API in a final CL. In that case, you need each team to sign off. This isn't too hard in practice, teams are generally expected to approve cleanups.
We usually have a 3 steps process. 1st new API interface/service using the new dependency is added and runs in parallel with the existing one, 2nd we blast email to users of old one to migrate to the new one, 3rd when usage of the old one hits 0 it is removed. When a team slacks off in migrating (usually we have months between receiving the first notification and service shutdown) things escalate and a director might get involved.
Anyway, this means that migrating to the new interface is clients' responsibility.
However there's an exception: if the changes are trivial (like changing the the name of one of the API endpoints), we have an automated tool that basically performs this change across the whole codebase. These kinds of changes still need to be approved by the codebase owners and shouldn't break any test, so they must be really trivial.
In this case is usually the team owning the API/Service that performs that.
Also note that "upgrading a dependency" is a relatively rare occurrence in the sense the I understand the question. Google definitely uses third party code but it is outstanding how much is proprietary Google owned and authored. For this code you don't release new versions and update, instead you evolve APIs gradually (as the other commenters have explained).
For third party dependencies there are two main options.
1. Do it all at once. This is good for relatively small numbers of users or small API changes.
2. Introduce the new version, migrate users, then delete the old version.
Note that for third party libraries Google does maintain a fairly strict one version policy so 2 is always a temporary measure.
Usually that problem is dealt with combination of:
* Automation.
* Ability to change other people's code safely, possibly gated by code review approval. Cultural and technical (e.g. unit tests must exist and be maintained) barriers may apply.
* Making incremental changes that are backward compatible (at least until you migrated all clients so you can cleanup later)
