Skip to content

Target DuckDB 2.0.0; v0.4.0 community-extensions descriptor - #18

Merged
BorisBesky merged 5 commits into
mainfrom
ccr-a35174e0-kx733o
Oct 22, 2026
Merged

BorisBesky merged 5 commits into
mainfrom
ccr-a35174e0-kx733o

Conversation

@BorisBesky

@BorisBesky BorisBesky commented Oct 22, 2026 •

Copy link
Copy Markdown
Owner

DuckDB 2.0 is released, so it becomes the stable target, and the descriptor is prepared for the community-extensions submission.

CI and submodules

  • duckdb-stable-build and the code-quality check: DuckDB v2.0.0 with the v2.0-cyanoptera extension-ci-tools — the same pair duckdb/community-extensions builds with (there is no v2.0.0 ci-tools branch).
  • The DuckDB 2.0 preview job becomes an informational DuckDB 1.5.6 build (no macOS): the source still supports 1.5, and community-extensions still publishes 1.5.6 builds.
  • Submodules: duckdb → v2.0.0 (d54cbbe), extension-ci-tools → 78bd1e4 (v2.0-cyanoptera).
  • WASM validation stays on 1.5: no @duckdb/duckdb-wasm release bundles DuckDB 2.0 yet (the newest, 1.33.1-dev65.0, bundles v1.5.6), so a 2.0 WASM build can't be loaded for testing. The 2.0 WASM builds still run in the main pipeline.

Source fixes

  • DuckDB 2.0 detection now keys on duckdb/common/vector/flat_vector.hpp. DuckDB 1.5.6 also ships duckdb/common/identifier.hpp (the previous probe), so 1.5.6 was mistaken for 2.0 and failed to compile on the missing 2.0 vector headers.
  • CMakeLists.txt reformatted: DuckDB 2.0's format check also runs cmake-format on it. Layout only.

Descriptor (description.yml)

  • version: 0.4.0. Extended description and README say the extension builds for DuckDB 2.0 and 1.5.
  • ⚠️ repo.ref is still 6641ec1 (the merge of Support DuckDB 2.0 alongside 1.5 #17), which does not build against DuckDB 1.5.6 (see the detection fix above). After this PR merges, ref must move to the merge commit before the descriptor is submitted to duckdb/community-extensions.

Test fix

  • DuckDB 2.0.0's plan renderer prints Filter where 1.5 printed FILTER; the integration test's EXPLAIN check now matches the operator case-insensitively as a whole word (so "Firestore Pushed Filters" still doesn't count).

Verified locally

  • DuckDB v2.0.0 (d54cbbe): builds cleanly; offline SQL tests pass (352 assertions); Firestore emulator integration 165/165; large-collection suite (mock server): unit 118/118, paging 50 assertions, integration 68/68.
  • DuckDB v1.5.6: builds with the detection fix; offline SQL tests pass (352 assertions).
  • Emulator integration 165/165 also on 1.5.5.

🤖 Generated with Claude Code

https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8

DuckDB 2.0 is released, so it becomes the stable target:

- duckdb-stable-build and the code-quality check use DuckDB v2.0.0 with the
  v2.0-cyanoptera extension-ci-tools, the pair duckdb/community-extensions
  builds with (there is no v2.0.0 ci-tools branch).
- The 2.0 preview job becomes an informational DuckDB 1.5.6 build: the
  source still supports 1.5 and community-extensions still publishes 1.5.6
  builds. No macOS there, as before.
- Submodules: duckdb -> v2.0.0 (d54cbbe), extension-ci-tools -> 78bd1e4.
- WASM validation stays on 1.5: no @duckdb/duckdb-wasm release bundles 2.0
  yet (the newest bundles v1.5.6), so a 2.0 build cannot be loaded there.
- description.yml: version 0.4.0, ref 6641ec1 (the 2.0 support merge; this
  commit changes only CI, submodule pins and docs, which the community
  build does not use). README and the extended description say 2.0 and 1.5.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8
The previous commit meant to move it with the duckdb submodule but kept the
old v1.5 pin.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8
DuckDB 2.0.0's plan renderer titles operators in mixed case ("Filter")
where 1.5 printed "FILTER", so the EXPLAIN check for the post-scan filter
failed on 2.0.0 although the filter is there. Match "filter" as a whole
word, case-insensitively; the scan's "Firestore Pushed Filters" line still
does not count. Passes on 2.0.0 and 1.5.5 (165/165).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8
DuckDB 2.0's scripts/format.py also runs cmake-format on the extension's
CMakeLists.txt, which 1.5's did not. Layout only; no build change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8
DuckDB 1.5.6 also ships duckdb/common/identifier.hpp, so it was taken for
2.0 and the build failed on the missing 2.0 vector headers. The
duckdb/common/vector/ headers exist only in 2.0.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8
@BorisBesky
BorisBesky merged commit 89f1537 into main Oct 22, 2026
19 checks passed
BorisBesky pushed a commit that referenced this pull request Oct 22, 2026
6641ec1 does not build against DuckDB 1.5.6 (its 2.0 detection mistook
1.5.6 for 2.0); 89f1537 has the fix and is what the v0.4.0
community-extensions submission builds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8
BorisBesky pushed a commit that referenced this pull request Oct 22, 2026
BorisBesky added a commit that referenced this pull request Oct 28, 2026
* Build against DuckDB 2.0.0 and submit v0.4.0 to community-extensions

DuckDB 2.0 is released, so it becomes the stable target:

- duckdb-stable-build and the code-quality check use DuckDB v2.0.0 with the
  v2.0-cyanoptera extension-ci-tools, the pair duckdb/community-extensions
  builds with (there is no v2.0.0 ci-tools branch).
- The 2.0 preview job becomes an informational DuckDB 1.5.6 build: the
  source still supports 1.5 and community-extensions still publishes 1.5.6
  builds. No macOS there, as before.
- Submodules: duckdb -> v2.0.0 (d54cbbe), extension-ci-tools -> 78bd1e4.
- WASM validation stays on 1.5: no @duckdb/duckdb-wasm release bundles 2.0
  yet (the newest bundles v1.5.6), so a 2.0 build cannot be loaded there.
- description.yml: version 0.4.0, ref 6641ec1 (the 2.0 support merge; this
  commit changes only CI, submodule pins and docs, which the community
  build does not use). README and the extended description say 2.0 and 1.5.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8

* Pin extension-ci-tools to v2.0-cyanoptera (78bd1e4)

The previous commit meant to move it with the duckdb submodule but kept the
old v1.5 pin.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8

* Integration test: accept DuckDB 2.0's "Filter" plan node

DuckDB 2.0.0's plan renderer titles operators in mixed case ("Filter")
where 1.5 printed "FILTER", so the EXPLAIN check for the post-scan filter
failed on 2.0.0 although the filter is there. Match "filter" as a whole
word, case-insensitively; the scan's "Firestore Pushed Filters" line still
does not count. Passes on 2.0.0 and 1.5.5 (165/165).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8

* Format CMakeLists.txt for DuckDB 2.0's format check

DuckDB 2.0's scripts/format.py also runs cmake-format on the extension's
CMakeLists.txt, which 1.5's did not. Layout only; no build change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8

* Detect DuckDB 2.0 by duckdb/common/vector/flat_vector.hpp

DuckDB 1.5.6 also ships duckdb/common/identifier.hpp, so it was taken for
2.0 and the build failed on the missing 2.0 vector headers. The
duckdb/common/vector/ headers exist only in 2.0.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8

* description.yml: point repo.ref at the #18 merge (89f1537)

6641ec1 does not build against DuckDB 1.5.6 (its 2.0 detection mistook
1.5.6 for 2.0); 89f1537 has the fix and is what the v0.4.0
community-extensions submission builds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8

* CI: build windows_arm64 against DuckDB 2.0

Windows ARM64 is opt-in in extension-ci-tools and in community-extensions,
and fire_duck_ext has never opted in, so no Windows ARM64 binaries are
published. Build it here first; once it is green, description.yml can
request it with opt_in_platforms. Opt-in archs also build on pull
requests (reduced CI mode does not drop them).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8

* Build OpenSSL with clang-cl on windows_arm64

MSVC 19.51 (VS 2026, used by the windows-11-arm runners) miscompiles
OpenSSL on ARM64 at /O2 /Gs0: the prologue calls __chkstk before
spilling lr, so tls_parse_all_extensions returns into its own prologue
and every TLS handshake crashes with an access violation
(openssl/openssl#26239). That is why firestore_types, firestore_batch
and firestore_orderby_limit_pushdown crashed on windows_arm64: they are
the tests that make a real HTTPS request.

Add an arm64-windows-static-release overlay triplet that chainloads a
clang-cl toolchain for the openssl port only, as duckdb-httpfs does.
Every other port and the extension itself still build with MSVC.

Verified on a Windows 11 ARM64 VM with the CI build steps (VS 2026,
DuckDB v2.0.0 prebuilt, extension-ci-tools v2.0-cyanoptera): all SQL
tests pass, where the MSVC-built OpenSSL crashed the three tests above.

* Opt into windows_arm64 in description.yml

Request Windows ARM64 builds from community-extensions now that the
branch's windows_arm64 CI job is green with OpenSSL built by clang-cl.

* Bump to 0.4.1 and test windows_arm64 on the DuckDB 1.5 build

community-extensions also publishes DuckDB 1.5.x builds, and the windows_arm64 opt-in applies to them, so build and test that path here too.

---------

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants