Given some extensions might not be compatible at the same time with both latest stable DuckDB (v1.0.0) and current main, say due to non-stable API changes, the descriptor gets an additional optional field ref_next, that if present is assumed to be the ref to be used when building against duckdb next.
There will be also a CI job testing again all currently distributed extensions, and building and testing them on all platforms against duckdb main version, using either ref_next, if present, or ref (that has to be always present).
Also any changes to extensions descriptor will, in the run-up to v1.1.0, both build ref against v1.0.0 AND ref_next or ref against main.
Close to releases
Decision tree that we envision for maintainers is as follow:
extension you maintain is compatible with both v1.0.0 and main:
great! congratulations, you are set
extension is NOT compatible with both at the same time:
keep ref to whatever you have now (that should keep working)
add changes / iterate to the extension repository so that it's compatible with latest duckdb
send a PR against community_extension with that git reference as ref_next
possibly iterate, now
Release
As part of the release process, community extensions ref_next will be swapped to ref, and extensions that successfully build and test will now be distributed for v1.1.0.
After release
Improve the extension you maintain, targeting the latest duckdb stable release. This would allow you to distribute changes to users.
This PR, together with initial work in https://github.com/duckdb/community-extensions/pull/81, makes Community Extensions ready to be built and tested against what would become DuckDB v1.1.0.
The version has not been tagged (yet, see https://duckdb.org/docs/dev/release_calendar#upcoming-releases for the calendar), so the second best thing is checking what happens when building (and testing) against duckdb current main branch.
Given some extensions might not be compatible at the same time with both latest stable DuckDB (
v1.0.0
) and current main, say due to non-stable API changes, the descriptor gets an additional optional fieldref_next
, that if present is assumed to be theref
to be used when building against duckdb next.There will be also a CI job testing again all currently distributed extensions, and building and testing them on all platforms against duckdb main version, using either
ref_next
, if present, orref
(that has to be always present).Also any changes to extensions descriptor will, in the run-up to v1.1.0, both build
ref
againstv1.0.0
ANDref_next
orref
againstmain
.Close to releases
Decision tree that we envision for maintainers is as follow:
v1.0.0
and main:ref_next
Release
As part of the release process, community extensions
ref_next
will be swapped toref
, and extensions that successfully build and test will now be distributed forv1.1.0
.After release
Improve the extension you maintain, targeting the latest duckdb stable release. This would allow you to distribute changes to users.