edit: The previous title was "Reproducibility in Disguise: Bazel, Dependencies, and the Versioning Lie"
Eh... the real lie is the signal version policy in the first place. It can be broken, at least in Google, and must be often otherwise there'd be massive gridlock.
If you want to bring in a new third-party library that has a dependency that already exists in the monorepo, you'd better _pray_ that the version in the monorepo is already compatible. If not, you have to update that library and potentially every target that depends on it, maybe transitively. Trying to do that can sometimes take years - no joke.
So the single-version policy flexes, and exceptions are supposed to be temporary, but they're not always.
In the end there are two competing sometimes good, sometimes bad goals:
- Libraries should be somewhat discouraged from making too many or too flippant breaking changes. By having to update clients, they feel the pain and take migration more into account.
- Libraries should be able to make real improvements, even if they are breaking changes, and having clients shouldn't burden them with unbounded costs. They should be able to distribute reasonable costs of updating by letting clients update on their own time with versioning.
Vendored third party packages only highlight this tension, because the external world has largely settled on versioning as the approach which clearly conflicts with signle-versions, but it really existed anyway.
Single version policy doesn't solve version conflicts but it does put it right in your face which is as good as we can do.
Without single versions, new packages to the SAT solver can introduce new duplicate shared objects secretly breaking your hermetic seal.
It doesn't hide the complexity like package managers do by picking a language package by SemVer and crossing our fingers that the shared objects included will work too.
Eh... the real lie is the signal version policy in the first place. It can be broken, at least in Google, and must be often otherwise there'd be massive gridlock.
If you want to bring in a new third-party library that has a dependency that already exists in the monorepo, you'd better _pray_ that the version in the monorepo is already compatible. If not, you have to update that library and potentially every target that depends on it, maybe transitively. Trying to do that can sometimes take years - no joke.
So the single-version policy flexes, and exceptions are supposed to be temporary, but they're not always.
In the end there are two competing sometimes good, sometimes bad goals:
- Libraries should be somewhat discouraged from making too many or too flippant breaking changes. By having to update clients, they feel the pain and take migration more into account.
- Libraries should be able to make real improvements, even if they are breaking changes, and having clients shouldn't burden them with unbounded costs. They should be able to distribute reasonable costs of updating by letting clients update on their own time with versioning.
Vendored third party packages only highlight this tension, because the external world has largely settled on versioning as the approach which clearly conflicts with signle-versions, but it really existed anyway.