“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