Reactions to "SemVer Won't Save You"

[florimondmanca]

Just stumbled upon Hynek's excellent write up on SemVer and how it affects the relationship between maintainers and users.

https://hynek.me/articles/semver-will-not-save-you/

Once you read it, you'll see there are some ideas there that apply to libraries as well.

For example, the idea that library should never pin the major versions of their dependencies, so as to not prevent users from benefiting upgrades, or to avoid them version conflicts. It's easier for users to pin themselves in case of breakage than to remove that pin.

I think it's an interesting point. I think for HTTPX we've been doing a great job at managing intentional breaking changes, including pointing users at pinning HTTPX themselves. So not sure what we could take away apart from the dependencies discussions as far as HTTPX is concerned.

But for Starlette, Uvicorn, and others, that might be an interesting read as well. :)

[euri10]

Interesting, overall very similar points than in https://snarky.ca/why-i-dont-like-semver/

[rgoupil]

And yet, following semver properly would avoid this sort of issues:
https://community.openai.com/t/error-with-openai-1-56-0-client-init-got-an-unexpected-keyword-argument-proxies/1040332
Next time you make a breaking change, please bump the major version, plain and simple.

[tomchristie]

Reasonable, yes.

Dropping a deprecated API in 0.27 -> 0.28 wasn't sufficiently cautious, as evidenced.