3 ms·
It's only really relevant when a) you release semver-incompatible upgrades (e.g., 1.x to 2.x), b) people use types from your library in their APIs, i.e., their
by geofft 6y ago
It's only really relevant when a) you release semver-incompatible upgrades (e.g., 1.x to 2.x), b) people use types from your library in their APIs, i.e., their types depend on yours, and c) your library is sufficiently widely used that people are likely to have transitive dependencies on it by multiple routes, such that a couple of their direct dependencies will have upgraded to your new version and a couple wouldn't have gotten around to it.
The 'libc' crate was a perfect storm of all three. It was still at 0.x, and the whole point of the library is to define types/bindings for others to use.
It also requires the FOSS model of independent owners, I guess, since that's why some consumers haven't upgraded. Inside a company and especially in a monorepo, someone - probably the person making the breaking change - would have just upgraded everyone at once. And a redistributor of FOSS like a Linux distro would have probably just patched everyone at once or held back upgrades until they could - in fact, this is the same shape of problem as upgrading from OpenSSL 1.0 to 1.1, or GTK 2 to 3, or libstdc++'s new ABI, or whatever.
- yjftsjthsd-h 6y ago> Inside a company and especially in a monorepo, someone - probably the person making the breaking change - would have just upgraded everyone at once. Ideally yes, in practice not always. The easy way to break it is of course political problems, but it's perfectly possible to be stuck in a situation where unfortunate design decisions early on leave you stuck unable to make breaking changes even if everyone is on the same side (at any rate, not without taking a massive service disruption that would violate our contracts with customers).
- samus 6y agoAt work we had that situation with Spring. In the far future, we would like to upgrade to Java > 8, which makes an upgrade to Spring 5 necessary. But the frontend module uses Spring Flow Portlets, which are deprecated and were removed in Spring 5. This was not really a concern though, until too many security issues were found that made the upgrade necessary. In the end we settled on leaving the frontend on Spring 4 and upgrading everything else. It is very ugly, but the only real issue so far is that Spring 4 cannot parse Spring MVC 5's REST encoding of exceptions. Fortunately, we will build a new frontend this year...