This is an automated email from the ASF dual-hosted git repository.
shahar1 pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/main by this push:
new 7e7e4a95e0c Add update-providers-next-version step to provider docs
skill (#68739)
7e7e4a95e0c is described below
commit 7e7e4a95e0c723302632240227fbecdcbe7d7fb8
Author: Shahar Epstein <[email protected]>
AuthorDate: Fri Jun 19 09:29:25 2026 +0300
Add update-providers-next-version step to provider docs skill (#68739)
* Add update-providers-next-version step to provider docs skill
The prepare-providers-documentation skill stopped after regenerating the
build templates and handed back to the regular release workflow, leaving
'breeze release-management update-providers-next-version' implicit. That
step resolves inter-provider dependencies pinned with '# use next version'
to the just-released versions and must run before the PR is opened; missing
it ships the wave with stale lower bounds and needs a follow-up PR to fix.
Make the skill run it as an explicit phase and check for it during
validation.
* Document the next-version step in the provider release guide
Reflect in README_RELEASE_PROVIDERS.md that the
prepare-providers-documentation
skill now runs update-providers-next-version itself, and that an incremental
update which bumps a version must re-run that step on the rebased branch —
for both the skill and the interactive breeze flows.
---
.../prepare-providers-documentation/SKILL.md | 34 +++++++++++++++++++++-
dev/README_RELEASE_PROVIDERS.md | 23 +++++++++++++++
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/.agents/skills/prepare-providers-documentation/SKILL.md
b/.agents/skills/prepare-providers-documentation/SKILL.md
index fb5602f894a..d3c90f546a7 100644
--- a/.agents/skills/prepare-providers-documentation/SKILL.md
+++ b/.agents/skills/prepare-providers-documentation/SKILL.md
@@ -487,6 +487,30 @@ new versions you just wrote. It will not touch
`changelog.rst`.
> `airflow-providers-commits` directive). It will be regenerated on the
> next full release. No action needed here.
+#### 4d. Resolve `# use next version` inter-provider pins
+
+Contributors can defer an inter-provider dependency bump by pinning it in
+`pyproject.toml` with a trailing `# use next version` comment, instead of
+hard-coding a version that does not exist yet. Now that the versions are
+bumped, resolve those pins:
+
+```bash
+breeze release-management update-providers-next-version
+```
+
+This rewrites every `# use next version` dependency to the just-bumped
+version of the referenced provider and removes the comment.
+
+> [!IMPORTANT]
+> **Run this every time, before opening the PR — even when you believe no
+> provider uses the comment** (the command is a safe no-op when none do).
+> Skipping it ships the wave with stale lower bounds on inter-provider
+> dependencies; once the PR is merged the only remedy is a separate
+> follow-up PR. This is the "Update versions of dependent providers to the
+> next version" step in `dev/README_RELEASE_PROVIDERS.md` — it lives between
+> doc preparation and PR creation, so it is easy to forget when the skill
+> hands back to the regular release workflow.
+
### Phase 5 — Validate
Run the same checks the release manager would run:
@@ -506,11 +530,14 @@ provider-by-provider:
- Confirm the version in `provider.yaml` matches the bump rule.
- Confirm `changelog.rst` has the right sections populated.
+- Confirm Phase 4d ran: no `# use next version` comment remains where the
+ referenced provider was bumped in this wave.
- Flag anything where Phase 3.5 had to escalate, so the RM can double-check.
Stop here. Do not commit, do not push — the release manager opens the PR
themselves following the regular release workflow in
-`dev/README_RELEASE_PROVIDERS.md`.
+`dev/README_RELEASE_PROVIDERS.md`. Make sure Phase 4d
+(`update-providers-next-version`) has been run before that PR is opened.
---
@@ -652,6 +679,11 @@ no leftover "Please review …" markers from a prior
interactive
incremental flow before invoking this skill), remove them as part of the
final pass. Then walk the diff with the release manager.
+If the incremental run bumped a provider to a *new* version (Incremental
+Phase 3.5), re-run Phase 4d (`update-providers-next-version`) as well — a
+`# use next version` pin on that provider must resolve to the freshly
+bumped version before the rebased PR is pushed.
+
---
## Cross-Cutting Rules
diff --git a/dev/README_RELEASE_PROVIDERS.md b/dev/README_RELEASE_PROVIDERS.md
index 36841800f72..d958fc68a08 100644
--- a/dev/README_RELEASE_PROVIDERS.md
+++ b/dev/README_RELEASE_PROVIDERS.md
@@ -282,6 +282,10 @@ uncertain or major-bump cases with you, and application
via direct edits to `pro
(`breeze release-management prepare-provider-documentation
--reapply-templates-only`) so the skill
stays consistent with the existing tooling.
+The skill also runs the [Update versions of dependent providers to the next
+version](#update-versions-of-dependent-providers-to-the-next-version) step for
you, so you do not
+need to run that command separately when using the skill.
+
If you set ``DISTRIBUTIONS_LIST``, the skill scopes itself to that subset
automatically.
The skill (and the underlying breeze tooling) determines the new version of
provider as follows:
@@ -323,6 +327,12 @@ removed.
breeze release-management update-providers-next-version
```
+> [!NOTE]
+> The `prepare-providers-documentation` skill runs this command automatically
as part of its
+> flow, so you only need to run it by hand when you prepared the documentation
with the
+> interactive breeze command instead of the skill. Run it regardless of
whether you think any
+> provider uses the `# use next version` comment — the command is a no-op when
none do.
+
## Create a PR with the changes
Make sure to set labels: `allow provider dependency bump` and `skip common
compat check` to the PR,
@@ -346,6 +356,13 @@ This usually takes some time, so before merging you need
to rebase it to latest
are no new, incremental updates (one or two merged commits in the meantime).
If there are - you still
have a chance to incorporate them via the **incremental update** flow.
+> [!IMPORTANT]
+> Whenever an incremental update bumps a provider's version, the [Update
versions of dependent
+> providers to the next
version](#update-versions-of-dependent-providers-to-the-next-version) step
+> must be applied **again** on the rebased branch — regardless of whether you
prepared the docs with
+> the skill or the interactive breeze command. The skill re-runs it
automatically; with the
+> interactive `--incremental-update` flow you must run the command yourself.
+
The recommended way is to invoke the same `prepare-providers-documentation`
skill — it has a dedicated
**Incremental Update** section that detects which commits on the rebased
branch are not yet referenced
in the existing `changelog.rst`, classifies only those new commits with the
same per-PR sub-agent
@@ -365,6 +382,9 @@ recognizes the incremental scenario and walks through:
4. Confirming any version-bump escalation with you explicitly before applying.
5. Inserting the new entries under the correct sections of the existing
latest-version block.
6. Validating that no leftover `Please review` markers remain.
+7. Re-running [Update versions of dependent providers to the next
+ version](#update-versions-of-dependent-providers-to-the-next-version) when
an incremental
+ bump raised a provider's version.
If you set ``DISTRIBUTIONS_LIST`` the incremental flow honors that scope
automatically.
@@ -398,6 +418,9 @@ changelogs. If there are, you need to add them to PR and
classify the changes ma
* remove the "Please review" comments generated by the incremental update
process
* if needed adjust version of provider - in changelog and provider.yaml, in
case the new
change changes classification of the upgrade (patchlevel/minor/major)
+* if a version was bumped, re-run [Update versions of dependent providers to
the next
+ version](#update-versions-of-dependent-providers-to-the-next-version) (the
interactive
+ `--incremental-update` command does not do it for you)
In case you want to also release a pre-installed provider that is in
``not-ready`` state (i.e. when
you want to release it before you switch their state to ``ready``), you need
to pass
