Putting the breaking change above the feature list, not after it, is the difference between someone reading it before they update and someone finding out after their gallery pages go blank. Say plainly what happens if a user does nothing, that’s the sentence people actually search their inbox for later.
Support
Draft a public changelog entry explaining a breaking change to users
A scenario prompt for announcing a breaking change in a major release, with the migration path stated up front, not buried below the fold.
Works with Claude / GPT1,900 uses★ 4.5
The prompt
support-changelog-breaking-change
Version 5.0 of your plugin removes the old [gallery] shortcode entirely, replacing it with a block-based gallery. Sites still using the shortcode in existing content will see it stop rendering after updating, unless they migrate first. DETAILS: [an automatic migration tool is included in 5.0 that converts existing [gallery] shortcodes to the new block on first login after update; it's opt-in via a one-click button in the admin notice, not automatic on update itself] Write the public changelog entry for this release. Requirements: - Lead with the breaking change itself, in plain language, in the first line, not buried under a list of new features. Someone skimming needs to know their content could break before they update. - State exactly what a user needs to do (click the migration tool in the admin notice) and what happens if they don't (shortcode stops rendering), not just "we recommend migrating." - Recommend testing on staging before updating production, specifically because this is a breaking change, not boilerplate advice tacked onto every release. - Keep new-feature announcements below the breaking-change section, don't let them compete for attention with something that could take down a customer's page. - Link out to a migration guide if one exists; if it doesn't yet, say so and give a support contact instead of a dead link. Replace the DETAILS block with your real release specifics before running this.