Add a command to take a prepared provider back out of a release - #71836
Open
potiuk wants to merge 2 commits into
Open
Add a command to take a prepared provider back out of a release#71836potiuk wants to merge 2 commits into
potiuk wants to merge 2 commits into
Conversation
Release managers hit this when review concludes a prepared provider's changes are internal after all: the changelog entry can be corrected, but the version bump and changelog section stay behind and the provider is still built and uploaded. The sequence that actually removes it from the wave - and the marker file that records it - was described nowhere outside the breeze sources. The pre-merge sweep only ever looked for providers missing from a wave, so the opposite direction had nothing watching it in either the manual or the agentic flow.
When review concludes that an already-prepared provider has no user-facing changes, correcting its changelog entry leaves the version bump and the changelog section behind, so the provider is still built and uploaded. Undoing that by hand is a restore-rerun-answer-N sequence that release managers repeatedly get wrong, and it is unavailable during an incremental update at all: that mode answers every question with yes, so the prompt that reclassifies a provider as doc-only never appears.
potiuk
requested review from
amoghrajesh,
ashb,
bugraoz93,
choo121600,
ephraimbuddy,
gopidesupavan,
jason810496,
jedcunningham,
jscheffl,
shahar1,
vatsrahul1001 and
vincbeck
as code owners
August 19, 2026 12:17
boring-cyborg
Bot
added
area:dev-tools
backport-to-v3-3-test
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When review concludes that an already-prepared provider has no user-facing changes, correcting its
changelog entry is not enough: the version bump and the changelog section stay behind, so the provider
is still built and uploaded to PyPI. Undoing that by hand is a restore → re-run → answer-
Nsequencethat release managers repeatedly get wrong, and the sequence was documented nowhere outside the breeze
sources.
It is also unreachable during an incremental update.
--incremental-updatecallsset_forced_answer("yes"), which makesuser_confirmanswer every prompt with yes — includingDo you want to leave the version for X as is?, the gate behind the existing reclassify-to-doc-onlypath. So at the point in the release where this decision is actually made, it could not be applied at all.
This adds a single command for it:
It restores the provider's
provider.yamlandchangelog.rstto their released state and recordsdocs/.latest-doc-only-change.txtfor you to commit. It reuses the existing doc-only marking path, sothese providers appear in the usual doc-only summary bucket. It requires an explicit provider list —
it takes providers out of a release, so defaulting to all of them would be the wrong failure mode —
and it refuses to write an empty marker when there is nothing to mark, since a bad marker would
silence that provider's next release too.
Documentation is added for both flows: the release guide gains a section explaining the difference
between a
doc-onlychangelog entry (package still ships) and the marker file (no PyPI artifact atall), and the
prepare-providers-documentationskill gains the matching case in its pre-merge sweep —which until now only looked for providers missing from a wave, never for providers that should no
longer be in one.
Raised on devlist Slack by the provider release managers.
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 5) following the guidelines