Migrate to category-folder changelog fragments - #1919
Draft
tconley1428 wants to merge 4 commits into
Draft
tconley1428 wants to merge 4 commits into
tconley1428 wants to merge 4 commits into
Conversation
This was referenced Oct 2, 2026
yuandrew
reviewed
Oct 2, 2026
|
|
||
| For each PR with user-facing changes, add a Markdown file in each applicable | ||
| category folder. Write high-level release notes describing what users can observe. | ||
| Use fun, whimsical, unique lowercase kebab-case filenames, such as |
Contributor
There was a problem hiding this comment.
should we set an explicit file name char limit?
jmaeagle99
reviewed
Oct 2, 2026
| the file contains only the entry, without a category or version heading: | ||
|
|
||
| ```markdown | ||
| - Reject unsupported activity executors when creating a worker, instead of |
Contributor
There was a problem hiding this comment.
Should these files just contain the content without formatting (e.g. remove the - and just write each paragraph on a single line). Then tooling can format as necessary and can handle multiline.
yuandrew
reviewed
Oct 2, 2026
| * Update public API documentation or doc comments for public behavior changes. | ||
| * Add a high-level changelog entry for user-facing changes according to the | ||
| existing `CHANGELOG.md` convention. | ||
| * For user-facing changes, add a Markdown fragment under `changelog/<category>/` |
Contributor
There was a problem hiding this comment.
since we're changing this, worth adding a note to try to keep CHANGELOG entries to a sentence or 2? I've found AI is typically way too verbose here, with like 5-10 line entries
This branch has not been deployed
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
3 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.
Move pending Python SDK release notes into per-PR Markdown files under category folders. Contributors choose fun, whimsical filenames and write only the note body. Release preparation prepends a dated section, copies fragment bodies verbatim, and removes exactly the consumed files after version and lockfile updates succeed.
CHANGELOG.mdcontains completed releases only.Use sdk-rust's shared tooling for fragment checks, changelog writing and consumption, dated-section extraction, and Core revision selection. Python updates its versions and lockfile first, then invokes the tool with the new release version and date. Python retains Git/PR orchestration; no hook or JSON release plan is needed. Switch the checkpoint to the alternative organization-wide fragment workflow and update contributor/agent guidance.
Dependencies:
Both dependencies are pinned to published PR commit SHAs so this draft can exercise the shared workflow before they merge. Re-pin if upstream commits change or are squash-merged.
Validation: 14 targeted release-script tests passed, along with import/format checks, targeted type checks, and actionlint. Rust tooling has 22 passing tests and targeted Clippy checks. A disposable checkout ran real
uv lock, consumed all seven migrated fragments, committed the prepared release, and verified the version and published notes through the actual release verifier. Duplicate and empty releases were rejected, and a late fragment was consumed by a subsequent release while preserving history. No release was pushed or published. No SDK release-version bump is required.Changelog validation failures leave the earlier local version/lockfile updates for inspection while preserving the changelog and fragments. Preparation stops before committing; filesystem failures during writes or deletion may require local recovery.