alt Hacker NewsWait, does urlib not use semvar? Don't remove APIs on minor releases people. A major release doesn't have to be a problem or a major redesign, you can do major release 400 for all I care, just don't break things on minor releases.
Lots of things not using semvar that I always just assumed did.
Replies
Python itself doesn't use semver.
semver is funny because it gives the illusion of working but does not work at all
Glory to 0ver: https://0ver.org/
+1
The industry has a solution for the exact problem the urllib is having (semver). Urllib just actively refuses to use it.
The value of semver has always been a lie. https://news.ycombinator.com/item?id=37426532
Making you distrust updates is absolutely the correct versioning method. Pin your versions in software you care about and establish a maintenance schedule. Trusting that people don't break things unintentionally all the time is extremely naive.
It was dumb and user-hostile to remove an interface for no good reason that just makes it more work for people to update, but everyone not pinning versions needs to acknowledge that they're choosing to live dangerously.
They article does validly point out that deprecation warnings don't work. Turns out in this day and age that the only thing you can reliably inform about changes is the package manager and its dependency solver, and pip requires semver or similar for that.
This, I think, is the crux of the matter.
As an example, I always knew urllib3 as one of the foundational packages that Requests uses. And I was curious, what versions of urllib3 does Requests pull in?
Well, according to https://github.com/psf/requests/blob/main/setup.cfg, it's this:
That is exactly the kind of dependency specification I would expect to see for a package that is using semver: The current version of urllib3 is 2.x, so with semver, you set up your dependencies to avoid the next major-version number (in this case, 3).So, it seems to me that even the Requests folks assumed urllib3 was using semver.