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.
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.
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.
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.
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?
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.
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 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.
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.
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.
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.
Readit News
> 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.
https://github.com/curl/curl/commit/c2df780a97d9913eb20a55d4...
Maybe it is a sign of bigger and more stable source code, that individual commits influence each other less.
> 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.
Some software developers are just cursed.
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.
Dropping support for a group of platforms is definitely something I'd consider a breaking change.
https://github.com/grpc/grpc-go/issues/3798
https://github.com/grpc/grpc-go/issues/3798#issuecomment-670...
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”
Definitely a sane policy on the internet.
Ofcourse we wish everyone would use semver...
Oh, just because the tests can't imagine what the environment on all those hundreds of millions of client machines is :)