Conversation
boring-cyborg
Bot
added
area:providers
kind:documentation
provider:airbyte
provider:alibaba
provider:amazon
boring-cyborg
Bot
added
provider:github
provider:google
shahar1
added
the
skip common compat check
01325b9 to
ef55e73
Compare
|
common.ai - on hold until further notice |
| Bug Fixes | ||
| ~~~~~~~~~ | ||
|
|
||
| * ``Fix LivyAsyncHook methods get_batch_state and get_batch_logs (#71867)`` |
There was a problem hiding this comment.
| * ``Fix LivyAsyncHook methods get_batch_state and get_batch_logs (#71867)`` | |
| * ``Fix LivyAsyncHook get_batch_state and get_batch_logs methods sending POST to Livy GET only endpoints (#71867)`` |
I'm not sure if we are doing changes like that, but if we are, I think that we could make this note a bit more precise.
There was a problem hiding this comment.
We do, I'll manually review the changelogs later today to ensure that they reflect the contents of respective PRs correctly
potiuk
left a comment
potiuk
left a comment
There was a problem hiding this comment.
Approving — mechanically this is one of the cleanest waves I've checked. Everything
below is context for the release thread rather than a gate on this PR.
What I checked and found clean
- Version consistency across
__init__.py/pyproject.toml/provider.yaml/
changelog.rst/README.rst/index.rstfor all 33 released providers — no drift. # use next versionresolution: exactly the two in the description
(fab→common-compat>=1.20.0,common.ai→standard>=1.19.1), none left over.- All five
.latest-doc-only-change.txtmarkers point at commits that really are
doc-only for that provider's tree (weaviate's slice of #72111 is a code comment). amazon's excluded-changes list is entirely test-only.- Semver spot-checks: #72155 as Feature in
common.aiand Bug Fix instandard
is right (the standard slice removes twoasserts and fixes aNone-responder
crash).cloudant4.3.6 for droppingcloudant_fakeis fine — internal mypy stubs. - All six majors carry a migration note;
common.aicovers all three of its
breaking changes.
Two coordination items for the release thread
Neither is a defect in this diff — both are calls for the release manager.
common.ai. Your own comment on this PR says "common.ai - on hold until further
notice", yet the diff bumps it 0.9.0 → 0.10.0 with three breaking changes and resolves
common.ai → standard>=1.19.1. If the hold still stands, that provider needs pulling
before the RC is cut; if it's stale, worth saying so on the thread since the standard
floor resolution rides on it.
#71976 and #72081. subhramit asked for both per the release thread; both are still
open and unmerged on main, so neither is here. #72081 (AthenaSparkOperator) targets
amazon, which is already at 10.0.0 — cheap to fold in while the major is open. #71976
targets influxdb, which isn't in this wave at all.
CI
Special tests / Pendulum2 test: core / Core...Serialization fails on
airflow-core/tests/unit/jobs/test_triggerer_job.py::test_trigger_log[trigger1-1-0]:
E assert '0 triggers currently running' in "... Triggerer's async thread was
blocked for 300.00 seconds, exceeding the config..."
This PR touches no airflow-core/ file — loaded-runner flake, not diff-caused. It's
still a failing required check, so that one job needs a rerun before the merge button
lights up.
Smaller observations
Three inline, none blocking — one content-loss item on providers/duckdb/README.rst
(the regeneration is correct, but the hand-written "DuckDB version compatibility"
section needs somewhere to live) and two .. note:: → .. warning:: nits on the
breaking-change blocks this PR authors.
This review was drafted by an AI-assisted tool and
confirmed by an Apache Airflow maintainer. The maintainer
approving this PR has read the findings and signed off. If
something feels off, please reply on the PR and a maintainer
will follow up.More on how Apache Airflow handles maintainer review:
contributing-docs/05_pull_requests.rst.
Drafted-by: Claude Opus 5; reviewed by @potiuk before posting
| `apache-airflow-providers-common-sql <https://airflow.apache.org/docs/apache-airflow-providers-common-sql>`_ ``common.sql`` | ||
| ============================================================================================================ ============== | ||
|
|
||
| DuckDB version compatibility |
There was a problem hiding this comment.
Regenerating this README is the right call — it was hand-written in #72845, and AGENTS.md § Boundaries says never "edit generated files by hand when a generation workflow exists". But the regeneration takes this section with it, and the guidance isn't wrong — it's the one thing a deployment persisting DuckDB files actually needs to know. After this lands it survives only as a comment in providers/duckdb/pyproject.toml, where no user will ever see it.
Worth moving into providers/duckdb/docs/ (index.rst or operators.rst) either here or in a quick follow-up, so the template regeneration stops eating it.
Separately, and worth recording so nobody "restores" it later: the Cross provider package dependencies table this hunk also removes advertised a [common.sql] extra that duckdb doesn't have — apache-airflow-providers-common-sql>=1.28.2 is a hard dependency in pyproject.toml and is already in the Requirements table above. That deletion is a fix, not a regression.
(duckdb isn't in this wave, so none of this reaches a published artifact — repo only.)
There was a problem hiding this comment.
@o-nikolas might be a bug in how the prepare-providers skill undestands the current settings in provider.yaml.
I'll release duckdb, I'll be happy for some improving the skill :)
There was a problem hiding this comment.
Might be related to this file:
https://github.com/apache/airflow/blob/main/providers/duckdb/docs/.latest-doc-only-change.txt
It points to commit by https://redirect.github.com/apache/airflow/pull/48849
There was a problem hiding this comment.
I dont think there is any issue with the PR, as far as I see it, duckdb will be included in this wave by just looking at the PR. That's only @potiuk who mentioned it will not be included
There was a problem hiding this comment.
That's only @potiuk who mentioned it will not be included
Actually the PR description states that too
| 2.0.0 | ||
| ..... | ||
|
|
||
| .. note:: |
There was a problem hiding this comment.
.. warning:: rather than .. note:: here? The rest of the wave uses warning for breaking-change migration blocks (amazon 10.0.0, edge3 5.0.0, git 1.0.0), and in this file specifically the note directly below is about response_kwargs becoming a template field — non-breaking. As written the silently-changed XCom shape and a template-field addition render at identical visual weight.
| 4.0.0 | ||
| ..... | ||
|
|
||
| .. note:: |
There was a problem hiding this comment.
Same nit as openai: .. warning:: would match amazon 10.0.0, edge3 5.0.0 and git 1.0.0, which all use warning for their breaking-change blocks. A required task_id on every existing PsrpOperator is squarely warning-grade.
ef55e73 to
bc76c0f
Compare
| `apache-airflow-providers-common-sql <https://airflow.apache.org/docs/apache-airflow-providers-common-sql>`_ ``common.sql`` | ||
| ============================================================================================================ ============== | ||
|
|
||
| DuckDB version compatibility |
| Breaking changes | ||
| ~~~~~~~~~~~~~~~~ | ||
|
|
||
| * ``Build deferred AWS hooks from the operator's own settings (#72171)`` |
76 providers are released and 1 is marked doc-only. The four major bumps (edge3, git, microsoft.psrp and openai) each remove or change a released public API, and every one carries a warning in its version section explaining the migration. amazon is a minor instead: the AWS team reviewed apache#72171 and considers the deferred-hook change a bug fix, so the warning about the triggerer no longer inheriting its host's boto3 defaults ships under 9.37.0 rather than a major. The wave is large because apache#73286 made every operator's connection id a template field across 61 providers, which is a user-facing feature in each of them. common.ai is prepared in a follow-up commit rather than this one, so that the rest of the wave can ship if its release is deferred.
Kept separate from the rest of the wave so this provider can be dropped without rewriting the release commit. The bump is 0.10.0 rather than 1.0.0 although the release contains breaking changes: the provider is still pre-1.0 and its API is expected to keep moving, so the 0.x signal is worth more to users than strict semver here.
bc76c0f to
9612792
Compare
This branch has not been deployed
6 participants
Regular provider release wave. 77 providers are released, 1 is marked doc-only, and the rest had only build/tooling churn and stay out.
Important
This PR needs the
allow provider dependency bumplabel. Two inter-provider>=floors were resolved from# use next versionpins (fab→common-compat>=1.20.0,common.ai→standard>=1.19.1), which trips thecheck_provider_dependency_bumpsselective check.Major bumps
EdgeExecutornow counts queued workloads against[core] parallelism(#72048)GIT_CONFIG_COUNTcredential helper; needs git >= 2.31 (#64105)PsrpOperatorno longer defaultstask_idtocmdlet(#73036)create_embeddingsreturns every embedding for list inputs (#71989)ErrorClassificationreinstated by #73501, but PydanticAI conn types renamed andSQLToolsetnow rejectsallowed_tables=None/[](#72853, #73381, #73452)common.aistays pre-1.0 deliberately: its breaking changes are real, but the API is still moving, so the 0.x signal is worth more to users than strict semver. It is prepared in a separate commit so it can be dropped without rewriting the release commit.Notable non-major entries
.. warning::about the triggerer no longer inheriting its host's boto3 defaults still ships — the runtime change is real, it just isn't a major.check-provider-yaml-validfails for it in the Breeze image withNo module named 'airflow.providers.duckdb'— the provider package is not installed there. That is pre-existing (nothing had touched itsprovider.yamlbefore, so the check never ran) and has to be fixed before duckdb can ship. Tracked in the review thread.Validation
dev/check_changelog_entries.py --fix— 77 changelogs, 0 unresolved problems.prek run --hook-stage pre-commit— no failures.breeze release-management prepare-provider-documentation --reapply-templates-onlyis idempotent.breeze release-management update-providers-next-versionrun; no# use next versionpins remain.Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 5) following the guidelines
🤖 Generated with Claude Code