Prepare providers release 2026-07-22#70256
Conversation
I assume the ready state in provider.yaml is wrong? |
You're correct, PR for fixing it: #70275 |
Miretpl
left a comment
There was a problem hiding this comment.
I don't know much about providers realease, but I tried to find something odd. Just two comments/questions.
Regular provider release wave: 3 major (microsoft.azure, ssh, sftp), 13 minor, 14 patch, 2 incremental (snowflake, postgres) and 16 doc-only providers. Version bumps and changelog entries were classified per the prepare-providers-documentation workflow.
Changelog sections are rendered by iterating git log without sorting, so newest-merge-first is the format readers and past releases have seen. Three providers drifted off it — two of them because the incremental flow appends new entries to the end of a section instead of inserting them at the top, where a newer commit belongs.
The http provider calls get_async_connection(hook=...), a parameter added by apache#69140 that has never been released. common.compat was left out of the wave, so the '# use next version' marker resolved to the already-published 1.16.0, whose signature does not accept it — installing http 6.0.5 alongside common-compat 1.16.0 raises TypeError in the triggerer. airbyte's only pending commit moves airbyte-api from the 0.x series to 1.x and stops installing requests, excluding every previously supported version of a hard dependency, which is a major bump rather than the patch it was given. Four more providers carried changelog sections that did not match the commits actually being released: cncf.kubernetes and apache.spark were each missing an entry, and sftp and ssh referenced the tracking issue instead of the merge request that shipped the change.
Rebasing the release branch pulled in two commits that landed on main after the wave was first classified. Without classifying them the published changelogs would omit a user-facing parameter that ships in amazon 9.33.0 and would still credit a system-test change that has since been reverted.
Several entries in this wave told users the wrong thing. weaviate raised its weaviate-client floor past every previously supported version with nothing in the changelog saying so, in a patch release that a routine upgrade would pick up silently. common.ai did the same to the skills extra, and cncf.kubernetes deprecated a KubernetesPodOperator argument without telling anyone what to rename it to. The remaining entries advertised build-tooling and contributor-doc changes that users cannot observe, including one naming an unrelated provider.
…elogs The Airflow 3 API server builds the connection form from provider metadata rather than by importing hooks, so adding these fields to provider.yaml is what makes them appear in the UI at all. Hive connections gain Ssl and Zoo Keeper Namespace, Azure gains Azure Cloud Environment, and Google and Snowflake gain fields of their own. Excluding the change hid a visible one from users.
…check Generated-by: Claude Code (Fable 5)
apache#70224 merged a few hours after this wave was cut, declaring a Verify SSL connection field and hidden-field behaviour for the Jira connection. That metadata ships to users through get_provider_info.py, so the provider needs a release for the connection form to gain the field.
apache#70308 landed on main after this wave was cut, bumping a bundled fab UI dependency. It joins the excluded block alongside the sibling fab-ui-package-updates group bumps already there, since these frontend dependency updates carry no user-facing behaviour change.
apache#69526 makes psycopg (v3) the default synchronous Postgres driver. The break it guards against — psycopg2 no longer being installed — only exists because this same wave makes psycopg2 an optional extra of the postgres provider; in the released state psycopg2 was a hard dependency and nothing was broken. The common.sql and pgvector slices therefore adapt to an in-wave change rather than fix released behaviour, so they are Misc, matching how the same PR is already classified in amazon, google, and celery. Postgres keeps its Breaking entry — that is where the default actually changes.
Regular provider release wave for 2026-07-22. Version bumps and changelog entries were classified per the
prepare-providers-documentationworkflow; all template-generated files were regenerated bybreeze release-management prepare-provider-documentation --reapply-templates-only.Summary (50 providers changed, 42 skipped as tooling/template-only):
requestsno longer installed).latest-doc-only-change.txtupdated, no version bump# use next versioninter-provider pins resolved: sftp → ssh>=6.0.0, http → common.compat>=1.17.0.Follow-up commits reconcile the wave against the commits actually being released:
git log, which the incremental flow had drifted off by appending newer entries at the bottom.# use next versionmarker resolve to the already-published 1.16.0 — but http 6.0.5 callsget_async_connection(hook=...), added in Honor async hook subclass overrides in get_async_connection #69140 and never released, so that pairing raisesTypeErrorin the triggerer. airbyte was re-classified from patch to major: its only pending commit movesairbyte-apito the 1.x series and stops installingrequests, excluding every previously supported version of a hard dependency. cncf.kubernetes and apache.spark were each missing an entry, and sftp/ssh cited the tracking issue (Remove/Replace DSSKey references from Airflow #54079) instead of the merge request that shipped the change (Remove DSS key support from SSH provider for Paramiko 4 #69669).Verify SSLconnection field and hidden-field behaviour in the provider'sprovider.yaml— metadata that ships to users viaget_provider_info.py. It is bumped 3.3.4 → 3.3.5 (Misc). The incremental flow now sweeps every provider and prompts before adding or dropping one, so a provider that gains a user-facing change mid-wave can no longer slip out of the release silently (apache/airflow skill PR: shahar1:incremental-detect-providers-joining-wave).Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.8, 1M context) following the guidelines