Yes they have a huge mono repository and tooling to update projects in it to specific versions. You don't get a choice really. You can go home one night with your project on say Java 7 and then wake up and find someone has migrated it to Java 8 because they've decided it's Java 8 now.
This is the crucial difference. Library developers at Google know all their reverse dependencies, and can easily build, test, notify, or fix all of them.
You can't do that with external FOSS libraries. The closest thing we have is deprecation log messages and blog posts with migration guides.
Their external FOSS dependencies are imported into the monorepo and are built from there. So they get to use the same pattern there. Someone who updates the copy of the dependency in the monorepo will see the test failures of their reverse dependencies at that time, before the change is merged to master.
(Yeah they use different version control terminology since their monorepo doesn't use git, but I've translated.)
> The closest thing we have is deprecation log messages and blog posts with migration guides.
Rust has crater, which can at least build/test/notify over a large chunk of the rust FOSS ecosystem. It won't pick up every project, granted, and I haven't heard of anyone really using it outside of compiler/stdlib development itself, but it's an example of something a bit closer to what google has.
There is in fact something of a philosophy at Google that it's both your problem and your fault if a dependency upgrades in a way that breaks your project without breaking any of your tests.
