Repository navigation
fix(version): flag breaking changes on the entry instead of in its description - #720
Merged
Merged
Conversation
…scription The commit parser recorded a `!` or `BREAKING CHANGE:` commit by writing `**BREAKING** ` into the description and never set `breaking`. LLM-enhanced notes rewrite the description, so the marker vanished, and with no flag the renderer added no Breaking section. The parser now sets `breaking: true` and leaves the description alone; the standing-PR changelog and the release preview, which printed the description directly, add the marker from the flag. Older manifests keep rendering from their prefixed text. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
Standing release PR: #614 · v0.42.0 queued (4 packages) · open 82d 23h 24m · ✅ ready to merge Release Preview — v0.41.2 → v0.41.3
These changes will be added to the release PR (#614) when merged: Changelogmonorepo 0.41.2 → 0.41.3
After merge — predicted release
Updated automatically by ReleaseKit |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
… apart when deduping `githubRelease.body: 'changelog'` printed only the description, so it lost the marker once it moved to the flag. The standing-PR changelog's dedupe key and version's repo-level entry map keyed on type and description, so a breaking and a non-breaking commit with the same subject merged and the breaking one could be dropped. Both keys now include the flag. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Owner
Author
|
@greptileai review plz |
Merged
This was referenced Oct 23, 2026
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.
Description
The version step's commit parser recorded a breaking change (a
type!:header or aBREAKING CHANGE:footer) by writing**BREAKING**into the entry's description, and never set thebreakingfield. Everything downstream that marks breaking changes reads that field: notes' markdown renderer (its Breaking section and per-entry marker) and the LLM prompt'sbreaking="true"attribute. Templates print only the description; #722 fixes those.So in LLM-enhanced notes the model rewrote the description, the prefix went with it, and no Breaking section appeared. #614's preview shows it: 0.42.0's five breaking changes (#616, #690, #694, #708, #674) are listed as ordinary entries, and their manifest entries have
breaking: nullwith the prefix in the text. #718 stopped the model clearing the flag, but the flag was never set.breaking: trueand leaves the description as the commit subject.changelog) now add the**BREAKING**marker from the flag.Related Issue(s)
None; seen in #614's release-notes preview. Follows #718.
Type of Change
feat— New featurefix— Bug fixdocs— Documentation changerefactor— Code refactoringtest— Adding or updating testschore— Maintenance, dependencies, toolingScope
@releasekit/version@releasekit/notes@releasekit/publish@releasekit/release@releasekit/config@releasekit/coreChecklist
pnpm lint)pnpm test)pnpm typecheck)Testing Notes
breaking: truewith the plain subject for both a!header and aBREAKING CHANGE:footer.changelogrelease body mark a flagged entry**BREAKING**; the standing-PR changelog and the repo-level entry map keep a breaking and a non-breaking entry with the same subject apart. Each fails without its fix.single.spec.ts: a breaking commit renders BREAKING in the generated changelog) passes, now through the flag.🤖 Generated with Claude Code
The PR appears safe to merge; both previously reported problems are fixed.Summary
Breaking changes now use
breaking: trueinstead of a marker stored indescription.Reviews (2) · Last reviewed commit: "fix: mark breaking changes in changelog ..." · Reviewed by Greptile