> What if the update is a security patch? Even a security fix is unlikely to affect every downstream user of a library except in egregious cases. But, if so, y

> What if the update is a security patch? Even a security fix is unlikely to affect every downstream user of a library except in egregious cases. But, if so, yes you update them all. (I'd say this is much less frequent than, I don't know, OpenSSL or log4j having a bug that makes us do this. The specific concern of an internal library having such a broad vulnerability is negligible in influencing our CI design.) > What happens when they inevitably do want a new feature, and have to fast-forward through months or years of interface updates all at once? You do it. > What happens when a developer wants to work on a feature that cuts across systems, and now has to re-learn the "old" way of doing things? You do it. I didn't say "it has no associated costs." But you need to weigh those costs against the other costs of a monorepo, and other costs in your CI/CD design generally. "Take longer to update a really old project once a year" is a much lower cost for us than "have a dedicated CI team to wrangle the tooling we need for automatic downstream pushes / a monorepo."