Sounds reasonable, thanks! Although, I thought that the cases that I discovered in 8.17 when the rate limits didn't seem to apply in certain run-time conditions compared the previous releases, (and thus, may incur unexpected problems and costs for libcurl clients in multi-transfer scenarios) meet the "annoying regressions" criteria.
But, of course, it is up for you guys to decide. Stefan's change at least allows to avoid the unexpected issues and costs with the new mechanism, so we can take it as a patch for 8.17. Thanks, Dmitry -----Original Message----- From: Daniel Stenberg <[email protected]> Sent: Thursday, January 15, 2026 4:31 AM To: Dmitry Karpov via curl-library <[email protected]> Cc: Stefan Eissing <[email protected]>; Dmitry Karpov <[email protected]> Subject: [EXTERNAL] Re: Rate limit regressions in libcurl 8.18.0 vs 8.17.0 On Wed, 14 Jan 2026, Dmitry Karpov via curl-library wrote: > I am wondering if it is possible if you guys can release libcurl > 8.18.1 with your change sooner than the 2026-03-04, so folks who are > willing to move to > 8.18 very soon (like my company) could take it? I would be happy to offer you a quote for such a service, but otherwise the answer is no. We do release-cycle breaking patch releases only when there are "annoying regressions" or serious security issues. This is neither (according to the team that makes the decisions). Further, the PR we discuss is not merged yet. We already do curl releases as frequent as we do to make sure that no one has to wait long for the next release. It is also easy for anyone to just patch their own build or use a daily snapshot, should they want to test drive changes before the pending release. -- / daniel.haxx.se || https://rock-solid.curl.dev -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
