Yes; it’s particularly bad when you mix languages like this.
I maintain the nodejs foundationdb libraries. Fdb doesn’t have a published wire protocol - bindings are expected to wrap a dynamically linked C library which contains the protocol implementation and net code. And that library is very “clever” - it leans heavily on codegen (via mono) and hand written asm to support a high performance actor model internally. The downstream effect is that FreeBSD support for database clients has only been added recently. There’s no native Apple M1 client support. There’s been issues with code signing in Java ... and so on. Generally you can only talk to a foundationdb server from an x86_64 client that runs Linux/macos/windows. Which is arbitrary and frustrating.
I hope wasm/wasi eventually becomes the standard for libraries like this. Then the binaries/packages we distribute can work in different languages, different OSes and different architectures without needing all this drama. Wasm bundles fit perfectly in pip/npm/etc. Write them in any language you want and they run fast & run everywhere.
I'm torn on this, In the past, I've been broken by changes breaking me.
On the other hand, you have you have an open source project that has to deal with the schedule/quality/cost trade off and people are expecting support for particular platforms without there being funding coming in to support those efforts. How much free work do they do so other people's company's continue to function?
Yeahhh, I understand the frustration of a breaking change to the build system, but I don't understand the vitriol at the maintainers.
Ultimately, projects upgrade/move. If you are dependent, that's something you need to deal with. If you're not ready to deal with it, then pin your dependencies until you are.
Many of the issues in the thread aren't necessarily problems with cryptography - for example pip not being able to deliver wheels to Alpine.
.. and to pin dependencies, or expect the occasional CI breakage. (you could argue a major version bump would've been nice instead of a minor one. but i don't even want to open that can of worms.)
Honestly, even with minor versions, I'd prefer to use something like dependabot, or for a bot to open a pull request bumping versions. Tons of authors mess up semver in subtle ways, it's just much easier to avoid problems if you just pin dependencies.
I've started doing this with Nix for my own Rust projects, using the technique described here[1]. Planning on setting up a GitHub workflow to automatically open pull requests with bumped versions of nixpkgs/rust.
Its not clear cut what all is included with semver. Is switching from a C89 to a C99 a semver-breaking change? Is using a Python 3.1-specific function a semver-breaking change? Is fixing a bug or adding a new feature a semver breaking change [1]?
There is no clear cut answer in all of these situations and applying purity tests to semver instead just push another crowd of developers to abandon semver completely, making it hard to get any information communicated from your dependencies up to you.
It's for this reason I've never liked the sprawling dependency-of-dependency mess that a lot of software projects seem to have.