I think there are 2 change-sets in this PR, the one connected to extensions and the one connected to binaries. I would separate the 2 since they are logically independent.

Extensions: LGTM, change should not be visible to external world (since it changed already a few times / it's recent / extensions you can get them through regular INSTALL)

Binaries: I am not sure I see it AND it's independent, so I would remove from PR and discuss that independently.

In particular, Linux binaries are distributed like:

    - uses: actions/upload-artifact@v4
      with:
        name: duckdb-binaries-linux-${{ matrix.config.arch }}
        path: |
          libduckdb-linux-${{ matrix.config.arch }}.zip
          duckdb_cli-linux-${{ matrix.config.arch }}.zip

that seems consistent to the Windows pre-this change.

Change can have sense, but it's more visible (since nightly download endpoint uses that) and would make more sense across the board.

libduckdb-linux-${{ matrix.config.arch }}.zip

yes! And duckdb_arch is linux_arm64 or linux_amd64, but for windows it is windows-amd64 or windows-arm64 https://github.com/duckdb/duckdb/blob/main/.github/workflows/Windows.yml#L109C27-L109C40

It makes sense that changes to the binaries names and to the extensions names should be PR'ed separately. I'll remove changes to binaries names from this PR and will open a follow-up PR with them

I think in the case of LinuxRelease:

arch: arm64, image: aarch64

so it then becomes libduckdb-linux-${{ matrix.config.arch }}.zip -> `libduckdb-linux-aarch64.zip (or the other one)

Thanks!!

I think in the case of LinuxRelease:

arch: arm64, image: aarch64

so it then becomes libduckdb-linux-${{ matrix.config.arch }}.zip -> `libduckdb-linux-aarch64.zip (or the other one)

I don't think that image variable is used in LinuxRelease workflow to create an archive file containing a binary, please take a look here

image variable is used once and not in the binaries names

Thanks!