A monorepo does make changes atomic in the code. There's no trap there.
You're talking about deployment, and yes when deployment is staggered, then obviously all atomic changes need to be backward-compatible, or else be very carefully orchestrated. But that doesn't have anything to do with monorepo vs polyrepo. That's just staggered deployment.
You have to deal with backwards compatibility in both cases. But at least with the monorepo you can see and track and merge all the changes related to a feature in one place, and be able to roll them back in one place.
There's no such thing as when deployment is staggered. It's a distributed problem, so by definition it is not synchronous.
(Or you turn services off for the duration of the deploy. Most companies do not want that these days.)
Also, you're missing this part of the article:
> While this is also possible in a world with many repositories, the requirement to do this change in multiple pull requests is often enough to remind engineers that breaking changes to a service contract are not safe to make.
I was talking about the concept of deployment in general. Yes, of course it's usually staggered for monorepos. I don't know why you're arguing about saying there's "no such thing as when" and then immediately point out a case of "when" immediately following. (And turning off services for 15 minutes at 2 am is definitely still a thing.)
And I'm not missing any part of the article. I was talking about your comment, and the fact that you are conflating two different things. A monorepo allows you to make atomic commits that a polyrepo does not, full stop. There's no trap there. Deployment is separate. You have to worry about breaking changes regardless of it being a polyrepo or monorepo. But a monorepo can make each atomic change far easier to track and manage and reason about.
There is also a question of what developers should be developing against. A typical monorepo approach allows many developers to develop only against trunk, and not have to allow the messy world of releases and deployments into their brain.
A monorepo does make changes atomic in the code. There's no trap there.
You're talking about deployment, and yes when deployment is staggered, then obviously all atomic changes need to be backward-compatible, or else be very carefully orchestrated. But that doesn't have anything to do with monorepo vs polyrepo. That's just staggered deployment.
You have to deal with backwards compatibility in both cases. But at least with the monorepo you can see and track and merge all the changes related to a feature in one place, and be able to roll them back in one place.