I'm a nobody, but surprises me that the revert (and so the original feature) didn't include any tests. I always imagined that a project like curl (no deadlines? no pressure? no bosses?) would lead to people to work on it at their own pace (so more tests maybe? Maybe not, I don't know)
> Apart form the little bug that caused it to crash in several test cases. (...)
> Exactly why this was not discovered in our tests and CI jobs before the release we have yet to figure out, but it is certainly more than just a little disturbing.
I always find it a small miracle that you can yank an individual git commit out of a program, and end up with a working program. If I commit anything, follow-up commits quickly make the original quickly a hard requirement.
Maybe it is a sign of bigger and more stable source code, that individual commits influence each other less.
Working on new, small bits of software often implies that a single commit will be more relevant to the rest of the codebase. The more code there is, the less any one particular line, on average, would matter.
Since there is no /s at the end I will assume it was not a joke. Most versioning schemes assume logic behind bumping numbers, please check for example „semantic versioning 2.0.0“
Is there a commitment from curl to use semver? If not, all the discussions about why the bump to v8 is void. We know a huge project that doesn't stick to semver and update major version whenever they want: Linux Kernel.
Linux kernel user facing APIs never break? It really depends on what you consider user facing. If you’ve ever relied on or considered sysfs to be a user facing API there have been numerous and severe breakages over time in the Linux kernel.
Solaris tried something like this for a while. While their competitors were releasing versions 4, 5 and 6 of their OS, Solaris was releasing version 2.4, 2.5 and 2.6. This made it look like they were just doing minor updates to Solaris, when they were in fact major new versions. Eventually they gave up and renamed solaris 2.7 to Solaris 7 just to keep up with the version numbering.
Ultimately it sounds like the policy is actually 0 “reallly bad ABI breaks” where “bad” is a subjective evaluation of how many bug reports they get or breaking something foundational (eg pulse audio). It’s just not possible to freeze the ABI because people may have found kernel bugs and worked around them and the fix for the kernel bug breaks the workaround. That’s what Hyrum’s law means and the Linux kernel doesn’t have a unique solution here. Don’t get me wrong. They do a fantastic job all things considered. But the “never break ABI” is more marketing than a hard and fast rule (but yes they generally get as close as is feasible to sticking to it)
ABI ≠ API. The ABI is a property of the program, the compiler (including options used during compilation), and the target platform. Semver only concerns itself with API, ABI isn't even a consideration there.
I doubt many practitioners of semver would agree that changing the behavior of a function in a breaking way would technically be a ok because it only covers the API signature. Semantic versioning frequently means “non-major version is ok to blindly update and not only will the code still compile it’ll also behave the same way at runtime”, branding notwithstanding.
“Public api never breaks” as OP posted, for example, is a reference to the Linux ABI policy
The best thing about curl is that developer tools of browsers (firefox for example) have a convenient "Copy as curl" feature that mimics the web request. The reason there isn't a "Copy as wget" option, I think, is the level of control that curl allows so the request can be tailored to exactly mimic the browser.
But when you want to recursively download a website, of course, nothing better than wget. curl doesn't support that, and you'll need to parse and fetch the urls recursively yourself with a script.
> The reason there isn't a "Copy as wget" option, I think, is the level of control that curl allows so the request can be tailored to exactly mimic the browser.
That's not true. You can read the code that generates the curl command, it's pretty straightforward:
The arguments it uses are --url, --data-raw, -X/--request, -H/--header, --compressed and --insecure, all of which Wget has an analog of. I think the reason is that they don't care to do it and/or they don't want to make that "Copy" dropdown too long.
That will only download the first argument. You need
--remote-name-all
instead of -O (--remote-name) to download all arguments files. It was in my opinion a mistake in the curl cli that remote-name works like output and needs to be repeated for each url. Remote-name-all is what rename-name should have been all along.
Bumping the major version for fun is actually a pain, since configure scripts set upperbounds on major versions to be future-proof, anticipating breaking changes. Now it's just another edge case to deal with, and old versions of curl-dependents to patch.
I'm clearly in the camp of "you can add and depreciate (experimental) features all you like in minor versions, but you should only remove them in major versions" camp.
Hyrum’s law. Rust mostly gets around this by requiring you run the nightly compiler and library in addition to explicitly opting into experimental pieces.
I do not consider that a breaking change because they are no longer supported. Prior versions of the application will still run. Breaking changes to me are at the API level for SUPPORTED platforms.
But it would break builds for those platforms, and unless the change was marked as breaking, they would be silently incorrect and/or need to go and implement special-casing on the versions in their build systems as the parent comment said.
I think that's a breaking change by most definitions.
In fact, it does break builds. I've seen it personally with several Go libraries: they drop support for e.g. Go 1.12 in some minor version and then suddenly "go install ./..." step in your CI stops to work. And since we're talking about Go 1.12, that is, pre-module days, fixing that entailed either a) upgrading your whole project to use modules; b) changing the build pipeline to explicitly check out the last working version of the library's repository into GOPATH in the pre-build step.
This is particularly nasty when it happens in mostly stable, rarely-updated internal projects because what was supposed to be a 5-minute, 3-line update turns into a several hours long wrangling match. Apparently, the code does rot and rust or something.
Typically removing support for a platform is considered breaking, because users on those platforms can still run the previous versions, but cannot upgrade beyond the point where support was dropped. Very commonly seen in various Node libraries dropping support for old LTS releases coming out of support, for example.
That's only true for a small portion of software released. I have an idea about where this fixation in semver comes from, but I can't really believe that everyone here is a web dev who wasn't around before semver started getting traction.
Looking at the comment section I feel assured that comments are a thing of the past. I wonder if those people would take the hurdle to send an email instead.
The death of the comment section has been greatly exaggerated...one comment, that the moderator didn't even see fit to remove. Ain't much.
Also funny that you wonder if people would take the hurdle to send an email instead. In this particular case, the author has in fact written about the torrent of email abuse he faces on multiple occasions, for example here [1]. Is his 2021 post evidence that email is a thing of the past?
Of course he will not get less email when closing the comment section. The question was if he will get more email abuse when closing the comment section.
At the time I wrote my comment here there were only one comment from Taran telling us what he gives about the topic and Daniel's reply to it. Should have made this more clear. It was to expect that comments will explode from HN visitors.
Well, they didn't, so this thread just ended up polluting the comment section with the very noise it sought to lament. HN comments in my experience are far more reasonable than you're describing, and the entitled "free stuff" attitude only comes up in response to things like big corporations yanking support for a project (see: Docker). Everyone loves curl and nobody is complaining about the amazing software built and maintained primarily by a single developer.
This happens every single time I make a new major release of a piece of software I maintain. There is always some mistake—even a typo in documentation—and it's the tiniest possible mistake, and there is always only exactly one mistake, but it's always enough to bug me so much that I have to make a patch release just to fix the one single mistake.
Yep, have definitely done this once or twice with Chalk. I don't recall a time that a X.0.0 wasn't immediately followed up with an X.0.1 release for some dumb mistake I made.
Is not a curse, it’s probability and statistics. If you make a major release, you touch a lot of places and there’s a higher likelihood of introducing a bug.
I review it 10 times before I make the release and spot nothing, but then spot something only immediately after I release it. Just like how I can only spot typos in emails after I've already sent them.
Comment section reminds me of those for VLC. No clue why people complain about free stuff no one forces them to use. Like, just pay someone to implement DNSSEC if you really need that in curl, or write it yourself.
> No clue why people complain about free stuff no one forces them to use
Just like roads. Nobody forces people to use them, you know; sure, some people might want to use them, to go for some place for some other non-road-related business but that's just their problem.
On a more serious note: people complain about "stuff" when they try to use that "stuff" to do something and it doesn't work no matter whether it's free or not, it's just human nature. As for "forced to use"... if you need to make a network request from command line, the options are basically curl or wget. Neither of them support your use case? Well, you can always just give up and not do whatever you intended to do, nobody forces you to achieve things anyhow.
uhhhh i wonder why the guy behind curl doesn't have a responsive website. Yeah I get it, he's a c++ developer and web design is not his job but it's not that hard
Bugs not being caught by tests seems like a big deal. I recently discovered a bug in the nodejs repl and couldn't get the tests to fail, even though there was a consistent infinite loop. It made me think about how many other tests are not surfacing bugs. It seems this is an example of at least one more.
102 comments
[ 179 ms ] story [ 2643 ms ] threadhttps://github.com/curl/curl/commit/c2df780a97d9913eb20a55d4...
> Apart form the little bug that caused it to crash in several test cases. (...)
> Exactly why this was not discovered in our tests and CI jobs before the release we have yet to figure out, but it is certainly more than just a little disturbing.
Maybe it is a sign of bigger and more stable source code, that individual commits influence each other less.
If your git history looks like a work log, you're not writing atomic commits.
And people should get comfortable with git commit --amend and interactive rebase.
Ofcourse we wish everyone would use semver...
Quite a few engineers has seen the sharper side of his tongue for not taking that mantra seriously enough
Solaris tried something like this for a while. While their competitors were releasing versions 4, 5 and 6 of their OS, Solaris was releasing version 2.4, 2.5 and 2.6. This made it look like they were just doing minor updates to Solaris, when they were in fact major new versions. Eventually they gave up and renamed solaris 2.7 to Solaris 7 just to keep up with the version numbering.
¹ https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS.1-...
² https://github.com/MiKTeX/miktex/issues/554
Yep:)
> So what's the point for semver?..
Exactly that: To trumpet it to the world - this project never broke compatibility, accept no substitutes.
> The Linux ABI definition is both fuzzy and controversial. Some ABI breaks are unavoidable. [1]
[1] http://she-devel.com/Chaiken_LinuxABI.pdf
Ultimately it sounds like the policy is actually 0 “reallly bad ABI breaks” where “bad” is a subjective evaluation of how many bug reports they get or breaking something foundational (eg pulse audio). It’s just not possible to freeze the ABI because people may have found kernel bugs and worked around them and the fix for the kernel bug breaks the workaround. That’s what Hyrum’s law means and the Linux kernel doesn’t have a unique solution here. Don’t get me wrong. They do a fantastic job all things considered. But the “never break ABI” is more marketing than a hard and fast rule (but yes they generally get as close as is feasible to sticking to it)
“Public api never breaks” as OP posted, for example, is a reference to the Linux ABI policy
Definitely a sane policy on the internet.
Update: Based on comments from @xorcist and @stabbles:
alias wget="curl -fLsS --no-clobber --remote-name-all"
But when you want to recursively download a website, of course, nothing better than wget. curl doesn't support that, and you'll need to parse and fetch the urls recursively yourself with a script.
It allows you to repeat a request that the browser did, but in your own terminal. It only downloads data, but doesn‘t run downloaded scripts.
> The reason there isn't a "Copy as wget" option, I think, is the level of control that curl allows so the request can be tailored to exactly mimic the browser.
That's not true. You can read the code that generates the curl command, it's pretty straightforward:
https://github.com/ChromeDevTools/devtools-frontend/blob/c9a...
The arguments it uses are --url, --data-raw, -X/--request, -H/--header, --compressed and --insecure, all of which Wget has an analog of. I think the reason is that they don't care to do it and/or they don't want to make that "Copy" dropdown too long.
Also, --no-clobber is very recent (v7.83), so unlikely to work in general.
So `curl -fLOsS ...`
What did Drew Devault ever do to you? He's a smart guy and quite nice to talk to. What's the problem?
https://github.com/grpc/grpc-go/issues/3798
https://github.com/grpc/grpc-go/issues/3798#issuecomment-670...
See the discussion on semver and experiments: https://github.com/semver/semver/issues/238
Dropping support for a group of platforms is definitely something I'd consider a breaking change.
I think that's a breaking change by most definitions.
This is particularly nasty when it happens in mostly stable, rarely-updated internal projects because what was supposed to be a 5-minute, 3-line update turns into a several hours long wrangling match. Apparently, the code does rot and rust or something.
If you want this project to use a particular versioning scheme then you should just argue for that directly.
[1] Other than this snippet :) : “on curl’s 25th birthday made it extra fun”
Oh, just because the tests can't imagine what the environment on all those hundreds of millions of client machines is :)
Also funny that you wonder if people would take the hurdle to send an email instead. In this particular case, the author has in fact written about the torrent of email abuse he faces on multiple occasions, for example here [1]. Is his 2021 post evidence that email is a thing of the past?
https://daniel.haxx.se/blog/2021/02/19/i-will-slaughter-you/
It's not only about the comments we can see, but also about those comments that get filtered out by the moderator
> Also funny that you wonder if people would take the hurdle to send an email instead.
Of course you also get non-friendly emails. I was wondering if the people that leave those comments would send an email instead.
If that's what he left in and responded to, what do you think he's taking out?
> wondering if the people that leave those comments would send an email instead
The evidence presented is that he gets abusive emails with a comment section...why would he get less emails if he closed the comment section?
Some software developers are just cursed.
> Replace this text with the error page you would like to serve to clients if your origin is offline.
Just like roads. Nobody forces people to use them, you know; sure, some people might want to use them, to go for some place for some other non-road-related business but that's just their problem.
On a more serious note: people complain about "stuff" when they try to use that "stuff" to do something and it doesn't work no matter whether it's free or not, it's just human nature. As for "forced to use"... if you need to make a network request from command line, the options are basically curl or wget. Neither of them support your use case? Well, you can always just give up and not do whatever you intended to do, nobody forces you to achieve things anyhow.
Open source software is not a public utility and not paid for with tax money, therefore your analogy is flawed.