Repository navigation
chore(release): hide runner-level types and restore the Features/Bug Fixes headings - #360
Merged
Merged
Conversation
…Fixes headings Three things the 2.1.0 changelog surfaced. The section headings had drifted. Everything up to 2.0.0 says "Features" and "Bug Fixes"; the generated 2.1.0 section said "Added" and "Fixed", so one file spoke two vocabularies depending on how far down you read. Renamed back to what the file already used. `ci`, `chore`, `test` and `style` are now hidden. Nine of the forty generated 2.1.0 entries were runner bumps and lockfile churn — "bump pnpm/action-setup from 6.0.9 to 6.0.10" tells a consumer of the SDK nothing. They stay mapped, so they still count toward the release; they just no longer print. RELEASING.md gains the body-line rule. release-please parses the commit body line by line, and a line shaped like a conventional commit becomes its own changelog entry. 2.1.0 shipped two of those: one body line began `docs: @comark/vue ^0.3.1 -> ^0.5.1`, and another began `docs:lint` — the name of a pnpm script, read as type `docs` plus a description. Also spelled out that the body never reaches the changelog, so a change needing a paragraph gets that paragraph added to the release PR by hand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F22e2ft66y7nuBJjzdThBr
IgorShevchik
pushed a commit
that referenced
this pull request
Aug 21, 2026
…parsed entries The [Unreleased] block's prose now sits in the matching 2.1.0 sections, detailed entries first and the generated subject lines after. Nothing was rewritten -- the paragraphs that explain a migration, a behaviour change or a live-portal verification are the half the generated subjects cannot carry, and they would have been stranded above the release otherwise. Also removed two entries release-please assembled from commit bodies rather than subjects: a line opening `docs: @comark/vue ^0.3.1 -> ^0.5.1`, and one opening `docs:lint`, where that was the name of a pnpm script and got read as a type plus a description. #360 documents the rule that prevents the next pair.
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.
Three things the generated 2.1.0 changelog surfaced, all found by reading it against the hand-written entries above it.
The headings had drifted
Everything up to and including 2.0.0 uses
### Features/### Bug Fixes. The generated 2.1.0 section said### Added/### Fixed, so the file spoke two vocabularies depending on how far down you read. Renamed back to what the file already used.ci/chore/test/styleare now hiddenNine of the forty generated 2.1.0 entries were runner bumps and lockfile churn.
bump pnpm/action-setup from 6.0.9 to 6.0.10tells someone consuming the SDK nothing, and previous hand-written releases never carried that class of entry.They stay mapped, not removed — so they still count toward the release as a patch and stay visible in the commit history. They simply do not print.
The body-line rule, in RELEASING.md
This one is a real trap rather than a matter of taste. release-please parses the commit body line by line, and any line shaped like a conventional commit becomes its own changelog entry. 2.1.0 shipped two of them:
docs: @comark/vue ^0.3.1 -> ^0.5.1 and @nuxtjs/mcp-toolkit …Docsbulletdocs:lint and \pnpm audit --audit-level=moderate` all pass.`Docsbullet reading "lint andpnpm audit…all pass"The second is the instructive one:
docs:lintwas the name of a pnpm script, and got read as typedocsplus a description. The guide now says not to open a body line with a bare word and a colon, and to put script names mid-sentence.While there, spelled out something the guide implied but never stated: the commit body does not reach the changelog at all, only the subject. So a change that genuinely needs a paragraph — a migration, a behaviour change, a "verified live against a portal" note — gets that paragraph added to the release PR's
CHANGELOG.mdby hand before merging. That is a deliberate edit on the release branch, not a return to maintaining[Unreleased].Effect on the standing release PR
#353 regenerates on merge, so the renamed headings and the hidden sections apply to 2.1.0 itself. The two junk
Docsentries come from already-merged commit bodies and will regenerate too — those get removed by hand on the release branch, together with folding the hand-written[Unreleased]prose into the 2.1.0 section.Verification
lint:md,md-internal-links, and a JSON parse of the config.Last reviewedstamp onRELEASING.mdrefreshed.Generated by Claude Code