[throwaways885]

> If you change your service’s API, just updating all of the other clients of your service in the repo is not sufficient to skirt the problem of different clients expecting different APIs.

Most Google APIs are written in protobuf, which is backwards compatible over the wire. This makes most changes painless, although caveat emptor as things can still get messy as they do in the real world. With something like a Java interface, it doesn't really matter if those APIs change because all the code is built and released together at HEAD.

[majormajor]

Backwards compatible from a parsing-this-message-won't-blow-up standpoint but not necessarily from a semantic meaning-of-each-field standpoint if your devs are ... clever ... enough. ;)

That discipline to commit to an API and meaning for each field and not keep tinkering with it in messy ways is an under-valued and under-evangelized aspect.

[roughly]

> With something like a Java interface, it doesn't really matter if those APIs change because all the code is built and released together at HEAD.

Right, this is the thing that winds up following from the monorepo - the monorepo problem goes away if we just release everything, the whole fuckin’ system, into production every time we make any update to master. If that’s your system, hats off to you, I’m not nearly that good of an engineer.

[barrkel]

It's actually easier, in many ways -- if you can manage to release continuously. It forces you to stage your code incrementally and you should be able to roll back things easily if you see breakage.

[throwaways885]

If your services are backwards compatible to talk to each other, then you don't need to release instantly. Making breaking changes is tricky, but you don't need to release everything.