“Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.”
Curl on changes in 8.0.0:
“There is only one actual “change” in this release. This is the first curl release to drop support for building on a systems that lack a working 64 bit data type. curl now requires that ‘long long‘ or an equivalent exists.”
This is a backwards-incompatible breaking change, though not to the public API (but I believe semver as used is understood to include ABI, supported environments, etc), and it’s likely only “theoretically” breaking (are there any existing platforms that don’t have 64-bit support that did build curl, and now can’t? Looks like Daniel posed this question back in Sep 22 and found there were not https://curl.se/mail/lib-2022-09/0099.html).
So semver is not respected to the letter (semver specifies that only public API matters), but it is respected in spirit (the breaking change is in supported build environments, which people do care about when picking versions), but it is also the smallest possible unit of change that still counts as a breaking change, so it’s a bit of a technicality as well.
Personally I’m quite satisfied with it, it takes a decent understanding of semver to produce a case this finely balanced on the edge of two technicalities, which gives me the impression of being playful with semver rather than disrespecting, or being unaware of, semver. YMMV
First: You should never trust semver anyways, not where it matters. Second: even in semver, you can bump all the way you want, especially the major version. Just don't skip bumping when you break stuff.
AFAIK, semantic versioning does not prohibit you from voluntarily increasing a version number at a more "important" place than the one you need to increase considering the changes you did. It just requires that you increase it if you do "hard" API/ABI changes that mandate an increase.
The line before the one you quoted gives their explanation: "We decided it was about time to reset the minor number down to more a manageable level and doing it exactly on curl’s 25th birthday made it extra fun."
How would that work ? cURL is built for request-reply usecases, with potentially long-lived connections, but once connected the handling happens outside of curl. irc is an interactive protocol, meaning that requests and replies would be handled inside cURL.
The most charitable view I can take of such comments is to mentally paraphrase them to: "I can rewrite the small subset of the curl CLI that I personally use, in a modern language, on top of an existing HTTP library, in a weekend hackathon". That doesn't seem so crazy.
What's stopping you from making a basic version? Just about everything supports HTTP 1.0 still so you can make a quick program that sends:
GET / HTTP/1.0
Host: example.com
over a socket and that's already mostly working. Figure out TLS. Then you just have to do command line parsing and add the stuff you parsed into your request.
[+] [-] ManuelKiessling|3 years ago|reply
[+] [-] azov|3 years ago|reply
There's probably a fair number of setups that more-or-less automatically upgrade to the next minor version, but not the next major.
[+] [-] nusaru|3 years ago|reply
I don’t know why, but this really, really bothers me. Why even use semver then?
[+] [-] fwlr|3 years ago|reply
“Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.”
Curl on changes in 8.0.0:
“There is only one actual “change” in this release. This is the first curl release to drop support for building on a systems that lack a working 64 bit data type. curl now requires that ‘long long‘ or an equivalent exists.”
This is a backwards-incompatible breaking change, though not to the public API (but I believe semver as used is understood to include ABI, supported environments, etc), and it’s likely only “theoretically” breaking (are there any existing platforms that don’t have 64-bit support that did build curl, and now can’t? Looks like Daniel posed this question back in Sep 22 and found there were not https://curl.se/mail/lib-2022-09/0099.html).
So semver is not respected to the letter (semver specifies that only public API matters), but it is respected in spirit (the breaking change is in supported build environments, which people do care about when picking versions), but it is also the smallest possible unit of change that still counts as a breaking change, so it’s a bit of a technicality as well.
Personally I’m quite satisfied with it, it takes a decent understanding of semver to produce a case this finely balanced on the edge of two technicalities, which gives me the impression of being playful with semver rather than disrespecting, or being unaware of, semver. YMMV
[+] [-] groestl|3 years ago|reply
[+] [-] Slartie|3 years ago|reply
[+] [-] eesmith|3 years ago|reply
[+] [-] HeavyFeather|3 years ago|reply
[+] [-] Semaphor|3 years ago|reply
They don’t?
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] Svip|3 years ago|reply
[+] [-] rakoo|3 years ago|reply
[+] [-] Faaak|3 years ago|reply
[+] [-] low_tech_love|3 years ago|reply
[+] [-] mctt|3 years ago|reply
[+] [-] coolgoose|3 years ago|reply
[+] [-] mfrw|3 years ago|reply
https://daniel.haxx.se/blog/2021/05/20/i-could-rewrite-curl/
[+] [-] scottlamb|3 years ago|reply
[+] [-] return_to_monke|3 years ago|reply
[+] [-] intelVISA|3 years ago|reply
[+] [-] aew4ytasghe5|3 years ago|reply
[+] [-] Razengan|3 years ago|reply
[+] [-] charcircuit|3 years ago|reply