Repository navigation
Target DuckDB 2.0.0; v0.4.0 community-extensions descriptor - #18
Merged
Merged
Conversation
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
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
…n as #18) # Conflicts: # description.yml
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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-buildand the code-quality check: DuckDBv2.0.0with thev2.0-cyanopteraextension-ci-tools — the same pairduckdb/community-extensionsbuilds with (there is nov2.0.0ci-tools branch).duckdb→ v2.0.0 (d54cbbe),extension-ci-tools→78bd1e4(v2.0-cyanoptera).@duckdb/duckdb-wasmrelease 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/common/vector/flat_vector.hpp. DuckDB 1.5.6 also shipsduckdb/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.txtreformatted: 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.refis still6641ec1(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,refmust move to the merge commit before the descriptor is submitted toduckdb/community-extensions.Test fix
Filterwhere 1.5 printedFILTER; 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
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.🤖 Generated with Claude Code
https://claude.ai/code/session_0159dLVN7efE1WXtE1L97Us8