Writing Release Announcements

Option B follows the Keep a Changelog format correctly:

Structure:
1. Version + date header — `## [2.4.1] - 2026-07-10` — machine-parseable, links to a git tag/diff in most tooling
2. Category heading — `### Fixed` — Keep a Changelog defines six standard categories: Added, Changed, Deprecated, Removed, Fixed, Security. Using the correct one lets readers scan for what matters to them (e.g. someone scanning only for Security entries)
3. Specific bullet — names the exact symptom (`ENOENT` crash), the trigger condition (Windows paths with spaces), the issue number (#412) for full context, and the fix mechanism (paths are now quoted) — a reader can identify in one line whether this release affects them

Why "bug fixes" (vague) fails readers:
A user who was NOT affected by this bug has no way to know whether they need to upgrade. A user who WAS affected can't confirm their issue is actually fixed without reading the source diff. Specific changelog entries let users self-triage in seconds.

Why "various fixes and improvements" is the most common changelog anti-pattern:
It provides zero information. Users cannot decide urgency, cannot search for their specific bug, and cannot verify the fix addresses their issue. This phrase should almost never appear in a well-maintained CHANGELOG.md.

The reader-first principle:
A changelog entry should answer: what changed, why it matters to me, and (for bugs) how do I know if I was affected. "Thanks to everyone" is nice but belongs in release notes prose, not as a substitute for the technical description.

Option B is the correct structure for major-version release notes with breaking changes:

What makes it effective:
1. Leads with the risk level — "major release with breaking changes" stated immediately, not buried — respects that some readers will stop reading after this sentence and go straight to the migration guide
2. Directive, not passive — "Read the migration guide before upgrading" (bolded) — tells the reader exactly what to do, not just that a guide exists
3. Names the headline breaking change specifically — `Client.connect()` → `Client.createConnection()` — with the deprecation history (#201, since v2.5) which shows this wasn't a surprise change, and the new capability gained (connection pooling) which explains the "why"
4. Scopes the migration effort — "most users only need to rename the method call" — this single sentence answers the reader's most urgent question ("how much work is this for me?") before they even open the migration guide
5. Flags the exception precisely — "small number of edge cases involving custom timeout handling" — tells affected users exactly what to look for, without forcing everyone to read every edge case

Why "upgrade at your own risk" fails:
It's alarming without being informative — it raises anxiety but gives no actionable guidance. Good breaking-change communication reduces uncertainty; this increases it.

Why "many exciting features, we hope you enjoy it" is inappropriate for a breaking release:
Marketing-style enthusiasm buries the operationally important information (breaking changes) under vague positive language. For infrastructure and library releases especially, engineers reading release notes want risk information first, celebration second (if at all).

Option B is the correct, technically grounded response to a changelog generation question:

Why this response works:
1. Asks for the specific PR — rather than guessing, gathers the exact data needed to diagnose the issue
2. Explains the actual mechanism — Conventional-Commit-based changelog generators (e.g. `standard-version`, `release-please`, `semantic-release`) parse commit prefixes and often deliberately exclude non-user-facing categories like `chore:`, `test:`, `ci:` from the public changelog — this is a design choice, not a bug, and is worth explaining so the contributor understands the system rather than just getting a fix
3. Names the two most common causes — a squash-merge that lost the original conventional prefix, or a category intentionally excluded — covers the vast majority of real cases
4. Commits to a concrete next step — checking the history and either fixing the changelog or filing a tooling bug — gives the contributor a clear resolution path rather than leaving them uncertain

Why this matters for contributor experience:
A missing changelog entry can feel like an erasure of credit for real work. Explaining the mechanism (rather than a vague "weird, I'll look into it") helps the contributor understand how to format future commits correctly, and reassures them the omission wasn't personal or arbitrary.

Automated changelog gotcha worth knowing:
Squash-and-merge on GitHub uses the PR title as the commit message by default — so if the PR title doesn't follow Conventional Commits (even if individual commits inside the PR did), the changelog generator often misses it entirely. This is the single most common cause of "my fix isn't in the changelog" complaints.

Option B is the correct approach to documenting a silent behavioral change:

Why "not technically breaking" isn't the right bar:
Semantic versioning is about API contracts, but changelogs exist to serve users, not just satisfy semver rules. A default value change that alters runtime behavior (timeouts, retry counts, batch sizes, logging verbosity) can silently break production systems even without an API signature change — e.g. requests to a slow legacy endpoint start failing after upgrade with no code change on the user's side.

Structure of the correct entry:
1. Bold, specific headline — "Default request timeout reduced from 30s to 10s" — impossible to miss when scanning
2. Rationale — "to better match typical API response times" — explains why, which builds trust that the change was deliberate
3. Actionable mitigation — "set `timeout: 30000` explicitly" — gives affected users the exact code change to preserve old behavior
4. Explicit label — "this is a behavioral change" — names the category clearly even though it doesn't fit neatly into semver's "breaking" bucket, so readers calibrate risk correctly

Why burying it in a footnote is harmful:
Users scan changelogs top-to-bottom expecting the most important information first (this is why Keep a Changelog groups by category, not chronology). A footnote treatment for something that can cause production incidents is a trust-eroding surprise when discovered later via a support ticket instead of the release notes.

Why bumping to a major version alone is insufficient:
Even if you do decide the change warrants a major bump (a reasonable, more conservative choice for genuinely risky behavioral changes), the version number alone tells users "something changed" but not what or how to adapt — the prose explanation is still required.