Repository navigation
Add shared changelog fragment tooling - #1625
Merged
Merged
Conversation
This was referenced Oct 2, 2026
tconley1428
marked this pull request as ready for review
October 5, 2026 17:10
chris-olszewski
approved these changes
Oct 5, 2026
chris-olszewski
left a comment
Member
There was a problem hiding this comment.
Overall makes sense, all of my comments are non-blocking
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
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.
Add shared category-folder changelog tooling for SDK release adapters. The new
changelog-toolCLI validates per-PR Markdown fragments, writes a dated release section and consumes its fragments, extracts dated release notes, and resolves Core commit ranges from parent-repository Git links.The existing range-note CLI remains available. Historical traversal now follows fragments through migration and release assembly without duplicating notes. Fragments contain the entry body without a leading list marker; tooling adds one bullet per nonempty line, allowing multiple entries in a fragment. Each entry occupies one line because each nonempty line becomes a separate list item. Agent guidance asks for concise entries, ideally one or two sentences. Breaking changes always use
:boom: Breaking Changes; empty releases are always allowed, and empty sections produce no notes. Shared tooling usesanyhowto preserve error context. SDK adapters update versions and lockfiles first, then invoke the shared tool with the release version and date; they retain commits and PR creation. Validation completes before changelog writes or fragment deletion. Rust's own contributor convention remains unchanged for this first adoption.Validation: 23 crate tests, targeted Clippy with warnings denied, and nightly formatting passed. Tests exercise real temporary Git repositories, fragment layout, body preservation, release assembly, validation failures without changelog mutation, PR diffs, and nested Core revision selection. A disposable Python SDK checkout also exercised real lockfile updates, release commits, published-note extraction, duplicate rejection and empty-release preparation/extraction, and a subsequent release consuming a late fragment.
The tooling crate remains unpublished; no SDK package version bump is required.
Companion PRs: