One of my past managers once said:

Why all open-source developers just won’t stop publishing new versions of their libraries?

He certainly didn’t hate progress as such. This phrase was said when after some dependency update, together with a fix for a security vulnerability, the update introduced a few breaking changes and halted actual product work for a good part of the week. Yet another time.

If you run a popular project, whether it’s a library or an API and you publish a breaking change - consider how much extra work you are forcing on every user of your code in the world. Any breaking change can cause many hours spent on just updating your dependency everywhere it’s used. If the change is not important enough for hundreds of developers to spend their time on adopting it, see if there’s a way in which you can eliminate it or make it smoother.

These breaking changes happen all over the place:

• Private Twitter Note taking app that I use, Memos, changes API from version to version and it drives the mobile app’s developer (Moe Memos) mad! When I install updates, I see the update notes from the App Store which say something along the lines of “they broke the API again”. And I get their frustration!
• And those changes don’t have to be epic. Once, few years ago, I updated by libcurl dependency from 7.73.0 to 7.74.0, which looked like a very minor update. However, somebody changed the default value of CURLOPT_FTP_SKIP_PASV_IP from 0 to 1, which broke FTP upload for certain websites in my project Xpiks for multiple users. Of course, I learned it already after I deployed new version and pushed the update.
• There’re also epic versions of that. For example, in November 2024 a small internal change in Canva’s API Gateway led to a massive site outage. Engineers had updated their telemetry/metrics library deployed to all API gateway tasks. The change was intended to improve observability, but unexpectedly re-registered metrics on every event loop, introducing heavy lock contention.

There’re the opposite mindsets, like the Linux kernel’s motto to “never break userspace [APIs]” or the Go’s promise of backward compatibility. Heck, even C++ programs from 80s are still compilable on any modern compiler. Can you say this about your favorite Javascript framework?

This backwards compatibility is the mindset worth adopting, in case you care about your users.