Prepare providers release 2026-08-01 - #70932
Conversation
boring-cyborg
Bot
added
area:providers
kind:documentation
provider:airbyte
provider:alibaba
provider:amazon
Regular provider release wave. 47 providers are released and 2 are doc-only; the remaining 47 with pending commits carry only regenerated docs or the previous wave's release commit, so they are deliberately left unreleased. Four providers -- google, common.ai, openlineage and clickhousedb -- were cut as rc1 in the 2026-07-22 wave but never published, so their in-tree version sections are extended rather than superseded. Cutting a new version on top of those would publish a changelog that skips a version users never received. Two entries in those sections advertised PRs that were reverted before release (apache#70087 in common.ai, apache#69161 in google) and have been moved to the excluded block so the changelog does not promise features that do not ship. Within-wave chains that net to no user-facing change are excluded rather than listed as paired entries, since a reader who never saw the intermediate form gains nothing from them. Chains with a residual change are collapsed into a single entry naming every PR involved. The google changelog carried a note above its first version header, which rendered it as a page-level note instead of a release note; it now sits inside the 22.3.0 section it describes.
The docs spellcheck build rejects 'untyped' and the British 'favour'.
Reviewer feedback: changelog entries should read in user-facing language, so internal abbreviations are spelled out, dependabot group titles name the actual packages and versions instead of a bare update count, and entries no longer describe changes in terms of our own test scaffolding. A version bump supersedes a provider's .latest-doc-only-change.txt marker, which had been suppressing earlier doc-only and tooling commits from the range. Those commits ship with these releases and are now recorded. The OpenAI note was sitting above the first version header, where it rendered as a page-level note rather than one belonging to the release that introduces the behavior it describes.
|
Pushed: rebased onto latest main and applied the review feedback.
The two generalizable points — expanding internal abbreviations, and requiring explicit dependabot titles — will go into the release skill as a separate PR, following #70258. Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting |
Keycloak was held back from the initial cut. Its pending work is user-facing -- bulk authorization methods, the IMPORT_ERRORS_ALL permission, and moving the Keycloak tokens out of the Airflow JWT claims into dedicated cookies -- so it releases with the rest of the wave rather than waiting. The token move signs every logged-in user out once on upgrade, because sessions created before it carry the tokens in a form the new refresh path cannot read. That is a deliberate consequence of the move rather than a defect, but operators should not have to discover it from a failed login, so it is called out in the changelog.
I don't think it's right. Chaning registry entry is Airflow internal change. It means we just need to update doc version. There is nothing to release in PyPi. |
Note taken. As a release manager, I will take consequences of that decision on me. This is really a 'pragmatic" rather than "purisic" decision. I expect there might be problems if we mix different versions and registry metadata and try to have "past version" having different metadata than the same version now. I have no idea if it will, but I think this is a risk I woul like to avoid. I am actually planning to yank 1.0.0 release once we release 1.0.1 precisely because it had wrong metadata - because both registry and releases is something we are responsible for - and if this bears no problems to our users, I prefer to "fix" both code and metadata in unambiguous way. |
That is your call but I think you are taking it too far. |
That for sure when it comes to yanking. That was just and idea so far, I have not yet decided to do it. But what actual problem do you see by releasing 1.0.1 now ? It will actually solve a problem that status of the provider reported in our official page will be good. But yes, I hear you. It means new binary released. Because I personally do not want to lose time on trying to correct registry to fix it in a different way (what I cal "pragmatic" way) BTW, I would happily reconsider not releasing 1.0.1 actually if someone will fix the registry to show the right status (incubating) for 1.0.0. We still have some time - but I am flying in a few hours so won't be able to lead it. If you make it happen - I will just drop 1.0.1 from the release. |
3 participants
Regular provider release wave for 2026-08-01. Versions and changelog entries were
classified with the
prepare-providers-documentationworkflow; all template-generatedfiles were regenerated by
breeze release-management prepare-provider-documentation --reapply-templates-only.47 providers released, 2 doc-only, 47 deliberately unreleased. The unreleased ones
have pending commits, but only
#68991(regeneratedREADME.rst/index.rst) and/or#70256(the previous wave's release commit), so there is nothing user-facing to ship.No major bumps in this wave. Eight breaking-change candidates were reviewed against
the released tags and all resolved to minor or patch.
common.compat 1.18.0, common.sql 2.1.0, edge3 4.3.0, elasticsearch 6.9.0, fab 3.8.0,
hashicorp 4.8.0, microsoft.azure 14.1.0, snowflake 6.16.0, standard 1.17.0
Four providers were cut as rc1 last wave and never published
google(22.3.0),common.ai(0.7.0),openlineage(2.20.0) andclickhousedb(1.0.1)are still at 22.2.2 / 0.6.0 / 2.19.0 / 1.0.0 on PyPI. Their existing in-tree sections are
extended rather than superseded — cutting a new version on top would publish a
changelog that skips a version users never received.
Two entries in those sections advertised PRs that were reverted before release and have
been moved to the excluded block, so the changelog no longer promises features that do not
ship:
common.ai:Add AWS services toolset for agents to access 1000+ APIs (#70087), fullyreverted by Revert AWS services toolset for common AI provider #70695
google:Preserve Dataform workflow invocation config (#69161), reverted by Revert Dataform workflow invocation dict normalization (#69161) #70395Other notes
allow provider dependency bumplabel.update-providers-next-versionresolved three
# use next versionpins toapache-airflow-providers-common-compat>=1.18.0(amazon, fab, keycloak); without the label
check_provider_dependency_bumpsfails CI.providers/keycloak/pyproject.tomlcontains only that pin resolution — no version bumpand no changelog entry, so keycloak is not released in this wave.
.. note::above its first version header, which renderedit as a page-level note rather than a release note. It now sits inside the 22.3.0 section
it describes. That was pre-existing on
main, not introduced here.google Preserve Dataform workflow invocation config #69161/Revert Dataform workflow invocation dict normalization (#69161) #70395, common.ai Add AWS services toolset for agents to access 1000+ APIs #70087/Revert AWS services toolset for common AI provider #70695, neo4j Fix Neo4jOperator templated query validation #70348/Fail Neo4jOperator argument mistakes at Dag parse time #70508) are excluded rather
than listed as paired entries. Chains with a residual change are collapsed into a single
entry naming every PR involved (e.g. standard Read HITLOperator subject/body into the summary lazily #70345/Make the HITLOperator summary extension point public #70391).
source-date-epoch; the four extended providers werestill carrying the previous wave's value.
Static checks:
prek --hook-stage pre-commit65 passed / 0 failed,--hook-stage manual4 passed / 0 failed.
--reapply-templates-onlyre-runs are idempotent.Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 5) following the guidelines