Make provider release changelog entries read for users, not for us - #70948
Open
potiuk wants to merge 1 commit into
Open
Make provider release changelog entries read for users, not for us#70948potiuk wants to merge 1 commit into
potiuk wants to merge 1 commit into
Conversation
Review of the 2026-08-01 wave turned up entries nobody outside the project could act on: internal abbreviations, Dependabot group subjects that named an update count instead of the packages, changes described by their lint directive, and our own test vocabulary leaking into user-facing notes. The skill previously said only 'do not paraphrase', which left no room to fix any of that. The wave also lost doc-only entries: a provider's doc-only marker suppresses older commits from the discovery range, and that suppression silently stops applying the moment the provider gets a real version bump, so a single discovery pass misses them. A note pushed out of place by prepending a new section had the same one-pass blind spot.
Member
Author
|
cc: @eladkal -> your request :) |
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
2 participants
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.
Follow-up to the review of #70932, in the spirit of #70258.
Changelog entries should read for users, not for us
The review of the 2026-08-01 wave found entries that only make sense inside the
project. The skill said "Subjects must be the original commit subject … Don't
paraphrase", which is right about not inventing behaviour but left no room to fix
wording. This adds an explicit carve-out — rewrite the wording, never the
claim — covering the four cases the review actually hit:
… to prevent KPO race condition (#70595)… to prevent KubernetesPodOperator race condition (#70595)Bump the fab-ui-package-updates group across 1 directory with 3 updates (#70604)Bump prettier to 3.9.6, stylelint to 17.14.1, webpack to 5.109.0 (#70604)Remove noqa:S101 from production code (#70378)Mark asserts under 'TYPE_CHECKING' in 'DocumentLoaderOperator' (#70378)Remove hard-coded deferrable crawler run from example_glue system test (#70206)Remove hard-coded deferrable crawler run from example_glue (#70206)The Phase 5 defect scan gains matching checks for internal abbreviations and for
version-less / grouped dependency bumps.
A version bump supersedes the doc-only marker
classify-provider-changesstarts a provider's range atdocs/.latest-doc-only-change.txtwhen that marker is present, so older doc-onlyand tooling commits stay hidden while nothing is pending. That suppression stops
applying the moment the provider gets a real version bump — but a single
discovery pass never sees the widened range, so those commits are dropped from
the release.
In the 2026-08-01 wave this silently lost
cohere#69649,dbt.cloud/presto/trino#69478 andpapermill#68322. The skill now says tore-run discovery after Phase 4a and names the tell: a provider whose commit count
grows between two runs with no new merges.
Misplaced notes have a second variant
Phase 5 already checked for a
.. note::above the first version header. Itmissed the case where prepending a new section pushes such a note below the new
excluded block — no longer at the top of the file, so a top-of-file scan skips it.
Hit
openai(#69506) in this wave;google(#70869) was the already-documentedvariant. The check is now per-section.
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 5) following the guidelines