[correct_horse]

pyca/cryptography replaced C code with Rust code without bumping the major semver. This broke people's CI because it removed support for certain platforms which Rust barely supports or doesn't support at all. People are arguing over this change in the github comments, but the problem from my perspective is just with semver. The maintainers didn't do semver right.

Edit: the maintainers didn't do semver right because the maintainers didn't do semver

[pca006132]

I think the maintainers mentioned that they don't use semver. https://github.com/pyca/cryptography/issues/5771#issuecommen...

[epage]

First, they don't use semver [0]

Python is all over the place with versioning, making it hard to predict what scheme anyone is using. People either falsely assume semver or just don't do any version constraints, both leading to problems. Whats unfortunate, is the Poetry project is putting their head in the sand on this and not letting you patch transitive dependency versions [1]

Even if they did use semver, its still a contentious topic within projects using semver of what all is "included". Some people take an idealistic perspective of "if it might break me" but any change can break them [2], making it impractical. I've seen others take this as a sign that semver is impractical and shouldn't be used. I feel its a limited but useful communication tool; we have to accept imperfections in its use.

[0] https://cryptography.io/en/latest/api-stability.html#version...

[1] https://github.com/python-poetry/poetry/issues/697

[2] https://xkcd.com/1172/

[correct_horse]

I did not realize how inconsistent python versioning is, or that compatible release (`~=`) doesn't use the semver way. https://www.python.org/dev/peps/pep-0440/#compatible-release

[brundolf]

Say what you will about the JavaScript ecosystem, but this is something it executes really well on