Alexander J. Semenuk
5d5e35fb9b
## Problem Windows builds break with a current local toolchain (Scoop LLVM 22.1.8, CMake 4.4.0, VS 2026), in two independent ways: 1. The build stops at curl's deliberate guard: `#error "no non-blocking method was found/used/set"` in `third-party/curl/lib/nonblock.c`. 2. From the second configure onward, `cmake --build` re-runs CMake in an endless loop (observed 42 consecutive reconfigure cycles in a single build). Likely the same mechanism behind the "endlessly building" VS 2026 note in `docs/setup/dev/vs.md`. ## Root cause 1. `third-party/curl/CMake/CurlTests.c` passes `int *` to `ioctlsocket()`, whose third parameter is `u_long *`. Clang 22 promotes `-Wincompatible-pointer-types` to a hard error in C, so the `HAVE_IOCTLSOCKET_FIONBIO` try_compile silently fails and `curl_config.h` never defines it. Upstream CI does not see this because the windows-2022 runner image ships an older LLVM. GCC 14 promotes the same warning to a hard error, which is very likely the `CurlTests.c.obj` failure reported from MSYS2 in open-goal/jak-project#3551. Upstream curl hit the identical problem with GCC 14 and fixed the probe in curl 8.8.0 (curl/curl#13578). 2. The root CMakeLists copies the build tree's `compile_commands.json` into `<src>/build/` for clangd using `configure_file()`, which registers its input as a configure dependency. CMake rewrites `compile_commands.json` late in every generation, after `CTestTestfile.cmake` and `cmake_install.cmake` (outputs of the same Ninja regen rule), so once the dependency is registered the rule is deterministically dirty and every `ninja` invocation re-runs CMake. A pristine first configure is safe (the file does not exist yet, so the `if(EXISTS ...)` guard skips the copy), which is why the loop looks machine- or IDE-specific. ## Fix 1. Per review, re-vendor `third-party/curl` at the `curl-8_21_0` tag (previously `curl-8_3_0`), which carries the upstream probe fix plus two years of upstream development; `vendor.yaml` updated to match. Adjustments the version jump forced: - curl 8.15 removed the native macOS Secure Transport backend (`CURL_USE_SECTRANSP`), so macOS now builds curl against OpenSSL like Linux. The two macOS workflows install Homebrew `openssl@3` and export `OPENSSL_ROOT_DIR` (keg-only), and the macOS setup docs gained the same two lines. - `CURL_BROTLI` / `CURL_ZSTD` switched to AUTO-detection in curl 8.10; pinned OFF to keep the previous no-compression behavior and avoid silently linking whatever the CI images happen to have. - curl's new top-level `BUILD_EXAMPLES` cache option (default ON) leaked into discord-rpc's identically named option and broke configure at a nonexistent `examples/send-presence` directory; pinned OFF ahead of the third-party subdirectories. The diff is dominated by the mechanical tag-tree swap under `third-party/curl` (linguist-vendored, collapsed in review). The hand-written changes are `CMakeLists.txt`, the two macOS workflows, `docs/setup/system/macos.md`, and `vendor.yaml`. 2. Swap `configure_file()` for `file(COPY ...)`: the same clangd copy with no configure dependency registered. (`file(COPY_FILE ... ONLY_IF_DIFFERENT)` would be cleaner still but requires CMake 3.21, above the declared `cmake_minimum_required(VERSION 3.10)`.) ## Test plan - [x] Fresh `cmake --preset Release-windows-clang` (LLVM 22, no cache seeding) completes and logs `Enabled SSL backends: Schannel`; the FIONBIO probe passes without the previous `#error` - [x] Full Windows Release build from scratch in the branch worktree (all 1422 targets) - [x] goalc-test suite: 1509 passed, 0 failed - [x] Second consecutive configure with `compile_commands.json` present: the regen rule in `build.ninja` has no `compile_commands.json` input; `<src>/build/compile_commands.json` is still refreshed for clangd - [x] Repeated `ninja` invocations after a full build no longer re-run CMake - [x] macOS Intel and ARM CI green (first exercise of the OpenSSL backend switch) --- I work off a self-hosted forge, so this GitHub account is quiet; the configure logs and ninja dirty-node traces from the investigation are available if anyone wants the raw data. (AI-assisted)
4.3 KiB
Vendored
Generated
curl release procedure - how to do a release
in the source code repo
-
edit
RELEASE-NOTESto be accurate -
update
docs/THANKS -
update the "past releases" section in
docs/VERSIONS.md -
make sure all relevant changes are committed on the master branch
-
tag the git repo in this style:
git tag -a curl-7_34_0. -a annotates the tag and we use underscores instead of dots in the version number. Make sure the tag is GPG signed (using -s). -
run
./scripts/dmaketgz 7.34.0to build the release tarballs. -
push the git commits and the new tag
-
GPG sign the 4 tarballs as
maketgzsuggests -
upload the 8 resulting files to the primary download directory
in the curl-www repo
-
edit
Makefile(version number and date), -
edit
_changes.html(insert changes+bugfixes from RELEASE-NOTES) -
commit all local changes
-
tag the repo with the same name as used for the source repo.
-
make sure all relevant changes are committed and pushed on the master branch
(the website then updates its contents automatically)
on GitHub
- edit the newly made release tag so that it is listed as the latest release
inform
-
send an email to curl-users, curl-announce and curl-library. Insert the RELEASE-NOTES into the mail.
-
if there are any advisories associated with the release, send each markdown file to the above lists as well as to
oss-security@lists.openwall.com(unless the problem is unique to the non-open operating systems)
celebrate
- suitable beverage intake is encouraged for the festivities
curl release scheduling
Release Cycle
We normally do releases every 8 weeks on Wednesdays. If important problems arise, we can insert releases outside the schedule or we can move the release date.
Each 8 week (56 days) release cycle is divided into three distinct periods:
-
During the first 10 calendar days after a release, we are in "cool down". We do not merge features but only bug-fixes. If a regression is reported, we might do a follow-up patch release.
-
During the following 3 weeks (21 days) there is a feature window: we allow new features and changes to curl and libcurl. If we accept any such changes, we bump the minor number used for the next release.
-
During the next 25 days we are in feature freeze. We do not merge any features or changes, and we only focus on fixing bugs and polishing things to make the pending release a solid one.
If a future release date happens to end up on a "bad date", like in the middle of common public holidays or when the lead release manager is unavailable, the release date can be moved forwards or backwards a full week. This is then advertised well in advance.
Release Candidates
We ship release candidate tarballs on three occasions in preparation for the pending release:
-
Release candidate one (rc1) ships the same Saturday the feature freeze starts. Twenty-five days before the release. Tagged like
rc-7_34_0-1. -
Release candidate two (rc2) ships nine days later, sixteen days before the release. On a Monday. Tagged like
rc-7_34_0-2. -
Release candidate three (rc3) ships nine days later, seven days before the release. On a Wednesday. Tagged like
rc-7_34_0-3.
Release candidate tarballs are ephemeral and each such tarball is only kept around for a few weeks. They are provided on their dedicated webpage at: https://curl.se/rc/
The git tags for release candidate are temporary and remain set only for a limited period of time.
Do not use release candidates in production. They are work in progress. Use them for testing and verification only. Use actual releases in production.
Critical problems
We can break the release cycle and do a patch release at any point if a critical enough problem is reported. There is no exact definition of how to assess such criticality, but if an issue is highly disturbing or has a security impact on a large enough share of the user population it might qualify.
If you think an issue qualifies, bring it to the curl-library mailing list and push for it.
Coming dates
Based on the description above, here are some planned future release dates:
- June 24, 2026
- September 2, 2026
- October 28, 2026
- December 23, 2026
- February 17, 2027
- April 14, 2027