Hacker News Reader

Comment by nusaru | Hacker News Reader

> There is no API nor ABI break in this version.

I don’t know why, but this really, really bothers me. Why even use semver then?

Semver 2.0 on major version:

“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

I don't think it violates SEMVER.

> It MAY also include minor and patch level changes.

I ultimately understand this as "I can release a patch as a major if I feel like it"

Seems like an ambiguity in semver, actually.

I understood that to mean you don’t have to break updates into their major, minor, and patch changes. Like if you’re at 7.88.2, you don’t have to put all your patches into update 7.88.3, then ten minutes later release 7.89.0 with your minor changes, and then ten minutes after that release 8.0.0 with just the major breaking changes. You can instead bundle them all as 8.0.0 because a major change can contain minor changes and patches, and besides it’s far more convenient to not have to break apart the update.

I do appreciate the logic of your understanding, that “breaking change therefore major version bump” does not imply “major version bump therefore breaking change”.

I would expect to see guidance exactly for that claim. I don't see it as ambiguous, I see it as a misunderstanding. The rules are not "must not contain no breaking changes".

It clearly says that breaking changes MUST be released in a major version. And it also says nothing about how “minor” and “patch” changes alone MUST NOT be released in a major version. So releasing only “minor” and “patch” changes is fine according to my interpretation of it.

> semver specifies that only public API matters

People get really hung up on what is, or isn't "technically" a change to the API. "This now breaks the build" is a change to the public API in the only sense that matters.

> 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

What?

> > 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. There is no API nor ABI break in this version.

Intentions-wise this has nothing to do with the Venerable SemVer.

They wanted to move to 8.0.0 on curl’s 25th birthday, so they made the smallest possible breaking change they could (changing which environments curl can build in), thus justifying a major version bump.

“There is no API nor ABI break in this version.”, he wrote.

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.

Being able to trust it is the entire raison d'être of semver. Everyone keeps complaining about it, but it's working splendid for hundreds of thousands of code bases.

It's best effort, and can make your life easier, but please treat it that way (best effort). For everything that matters, review and test even revision bumps.

With third-party code, you're always relying on the best effort of others. Of course a version number doesn't relieve you of the need to run tests on your code base, but the probability for semver issues and code bugs should be about equally high - so there's no reason to trust one but not the other.

I think it can be okay in ecosystems where developers understand and respect semver

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."

I read that too, but I feel like a project as widely used as curl should be more “conservative” in their version increments.

They really are: https://daniel.haxx.se/blog/2013/03/23/why-no-curl-8/

Well linux incremented from 2 to 3 mostly because they felt like it, so they are in good company.

Why? It's just a number.

Well, Windows jumped from 4.0 to 2000

Internally Windows 2000 was WinNT 5.0. The marketing name doesn’t have to reflect software versions.

Major instead of patch is far better than patch instead of major. Nothing breaks due to this new version.

> Why even use semver then?

They don’t?

Well yeah, but it looks like semver. Again, I don’t know why it bothers me, but it just... does.

That’s a version number. Semver is a way of versioning. Now, saying "it bothers me that they don’t use semver" (which has them in the company of other small projects like typescript or the linux kernel) is a statement you can make, but "why use semver" when they don’t makes little sense.

True. I could have phrased that better. I’ll take this as a sign to go to bed. Good night!

Semver is a set of conventions on an older versioning scheme. The semver 1.0.0 spec (I think from 2010?) even points out:

> This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that “close” isn’t good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management.

Thus, X.Y.Z does not automatically mean "semver". Nor does even X.0.0 mean semver.

To give some 20th century counter-examples found through Google Scholar:

"System Description: Spass Version 1.0.0" (1999) https://link.springer.com/chapter/10.1007/3-540-48660-7_34

"This is version 2.0.0 of the software." (1999) https://econpapers.repec.org/software/bocbocode/s365703.htm

"This report provides the NIKE3D user's manual update summary for changes made from version 3.0.0 April 24, 1995 to version 3.3.6 March 24, 2000" - https://www.osti.gov/servlets/purl/15004757

It's rather than semver looks like it. Curl predates semver by 15 years. People have been numbering their software release as $major.$minor.$patch forever.

Oh yeah. The `x.y.z` notation that already existed and that SemVer just adopted is totally a surefire signal that “SemVer Here”.

You’ve got the order of events all mixed up.

Reply on news.ycombinator.com