3 ms·

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 yo

by dalore 7y ago

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.

paulddraper 7y ago
But that change only happened once all the tests for "your project" passed on Java 8.
- HeWhoLurksLate 7y ago
  So now you're saying that I have to write tests? /s
  - dodobirdlord 7y ago
    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.
- koala_man 7y ago
  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.
  - MaulingMonkey 7y ago
    > 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.
  - jkaplowitz 7y ago
    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.)

by dalore 7y ago

paulddraper 7y ago

But that change only happened once all the tests for "your project" passed on Java 8.

HeWhoLurksLate 7y ago
So now you're saying that I have to write tests? /s
- dodobirdlord 7y ago
  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.
koala_man 7y ago
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.
- MaulingMonkey 7y ago
  > 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.
- jkaplowitz 7y ago
  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.)