Re: On more stable curl releases

On Tue, Mar 21, 2023 at 12:40:28PM -0400, Timothe Litt via curl-library wrote: I expect that with frequent patch releases, curl would end up in the situation of most M$ releases whose strategy is- "wait for the other people to find the bugs and only take the nth patch release."  And with fewer

Re: On more stable curl releases

On Wed, Mar 22, 2023 at 12:10:56AM +0100, Daniel Stenberg wrote: BTW, "regression" is just another word for "test coverage gap", since if we had tested the thing we would've detected the problem and the bug would not have been shipped. It is important that we learn from the regressions and

Re: On more stable curl releases

Daniel Stenberg via curl-library writes: > On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote: > >> Some examples of regressions would be the crash that prompted >> yesterday's 8.0.1 point release, the noproxy host matching bug #9842 >> (fixed in 7.86.0) and the wrong units bug in

Re: On more stable curl releases

On Tue, 21 Mar 2023, Dan Fandrich via curl-library wrote: Some examples of regressions would be the crash that prompted yesterday's 8.0.1 point release, the noproxy host matching bug #9842 (fixed in 7.86.0) and the wrong units bug in --write-out %{time_total} (fixed in 7.75.0). Of these three

Re: On more stable curl releases

I agree with the problem statement.  But there's no easy answer. I expect that with frequent patch releases, curl would end up in the situation of most M$ releases whose strategy is- "wait for the other people to find the bugs and only take the nth patch release."  And with fewer users, the

Re: Recommended way of using a custom build of libcurl in a Node.js addon

HTTP/3 is experimental.  Do you want your non-technical users to rely on an experimental implementation? Do you have http/3 -only servers that your addon must communicate with?  (That would be unusual.) Unless that's the case, in the situation you describe, I'd wait for http/3 to be in the

On more stable curl releases

I've been getting a feeling that there have been more curl functional regressions (compared to plain bugs) in releases over the last few years. I don't know if that's true or not, but the pace of bug fixes generally has been going up (see https://curl.se/dashboard1.html#bugfix-frequency). I'm

Re: post-mortem: the 8.0.0 mishap

On Tue, Mar 21, 2023 at 2:32 PM Daniel Stenberg via curl-library < curl-library@lists.haxx.se> wrote: > Hi, > > We worked out exactly WHY we shipped curl 8.0.0 with a problem that caused > immediate test failures. > > A while back we merged several CI job files into a single "linux.yml" file > to

Re: Recommended way of using a custom build of libcurl in a Node.js addon

The primary reason why I thought that the deps should be bundled with the addon is that the application that would be using the addon needs libcurl with HTTP3 support through OpenSSL. The only option I found is to use the first one from https://curl.se/docs/http3.html - the ngtcp2 version which

post-mortem: the 8.0.0 mishap

Hi, We worked out exactly WHY we shipped curl 8.0.0 with a problem that caused immediate test failures. A while back we merged several CI job files into a single "linux.yml" file to make them easier to manage. In that (multi state) merge, some of the old CI jobs had valgrind enabled when

Re: Recommended way of using a custom build of libcurl in a Node.js addon

On 21-Mar-23 04:34, Darshan Sen via curl-library wrote: Hi! I'd like to incorporate a custom build of libcurl (with HTTP3 support) into a Node.js C++ addon that is going to be shipped to some systems that don't have curl or its dependencies installed.

Recommended way of using a custom build of libcurl in a Node.js addon

Hi! I'd like to incorporate a custom build of libcurl (with HTTP3 support) into a Node.js C++ addon that is going to be shipped to some systems that don't have curl or its dependencies installed. >From what I can tell, the possible ways in which this can be