[thundergolfer]

The old version won't coexist when the change is contained within a single binary, which seems like it would be true in a bunch of cases.

In our monorepo we have to treat database changes with care, like you mention, as well as HTTP client/server API changes, but a bunch of stuff can be refactored cleanly without concern for backwards compatibility.

[withinboredom]

Do you only have a single instance of the binary running across the whole org? And during deployment to you stop the running instance before starting the new one?

[jvolkman]

Any change that won't cross deployable binary boundaries (think docker container) can be made atomically without care about subsequent deployment schedules. So this doesn't work for DB changes or client/server API changes as mentioned by OP, but does work for changes to shared libraries that get packaged into the deployment artifacts. For example, changing the interface in an internal shared library, or updating the version of a shared external library.

[kohlerm]

Seems like a common misconception to me that people seem to believe that you can never change an interface. You actually can as long as it is not published to be used outside of your repositories.

[rutthenut]

That is only likely to apply in very small-scale environments or companies.

And if only a single binary is produced, quite likely a single source code repo would be used as well - sounds like 'single developer mode', well 'small team' at most.

[thundergolfer]

Our monorepo is millions of lines of source code, and hundreds of developers. Not small scale.

In this scenario, the single binary is the key encapsulation boundary, but your monorepo could be producing N binaries, each of which receives the change.

For example, if the change is to remove a single, unnecessary allocation in a low-level library function used across the repo, you can refactor it out and push the change as N binaries without worrying about compatibility.