Standardize release notes: always significant-change highlights, never a size-based trim - #19
Merged
Conversation
…r a size-based trim Replaces the 40-line cutoff (which only fell back to headings-only past that threshold) with one uniform rule applied unconditionally: the GitHub Release body is always just this project's ### heading bullets from CHANGELOG.md's matching section, plus a link back to CHANGELOG.md for the full write-up. CLAUDE.md's "Changelog policy" now documents why that heading convention matters beyond readability. Same change applied to CoverDex's and ThePatientGamerHelper's release.yml for consistency between the three projects' pipelines.
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.
Summary
This replaces the existing 40-line cutoff (a short section used verbatim, a long one abridged to headings-only) with one uniform rule, applied the same way across 3DSAppManager, CoverDex, and ThePatientGamerHelper's
release.yml:### <Type>: <summary>heading bullets fromCHANGELOG.md's matching section — never the full section text, and never gated by a line-count judgment call.CLAUDE.md's "Changelog policy" section now spells out why the heading convention matters beyond readability: the release workflow publishes those heading lines verbatim as the Release body, so a sloppy heading ships straight to the Release page as-is.###headings at all falls back to publishing the whole section as-is instead — a structural fallback for a section with nothing to extract, not a size cutoff.CHANGELOG.md's matching dated section, via GitHub's real heading-anchor slug algorithm (unchanged from before).## Unreleasedentry describing the old 40-line behavior with one describing this change instead, since the old entry was describing behavior that never shipped in a release.Supersedes #18, which proposed the same idea but left the actual extraction gated behind the 40-line threshold (and its own
CHANGELOG.mddescription was inconsistent with its code, describing a 1500-character cutoff that wasn't what the code did) — closing that PR in favor of this unconditional approach, applied uniformly with the other two repos.Test plan
python3 -c "import yaml; yaml.safe_load(open('.github/workflows/release.yml'))"— YAML parses.### Fix:/### Changed:/### Removed:headings with prose+bullets underneath) — correctly collapses to just the three heading lines, ignoring the bullets under them.make testnot re-run in this pass — this change only touches.github/workflows/release.yml,CLAUDE.md, andCHANGELOG.md, none of which affectsource/.workflow_dispatch(would cut a real release, and the real build requires devkitARM which isn't available in this sandbox).Generated by Claude Code