release-announcement

# Release Announcement Write the channel-appropriate announcement for a release without churn. Different surfaces need different shapes: a changelog entry is not a blog post is not a social card. The bar is: a reader of the chosen surface can decide in under 30 seconds whether this release affects them, and if so what to do. ## When to use - A version, feature, or fix is shipping and needs writeup for at least one surface. - A previously private feature is going GA. - A breaking change needs broadcast before users hit it. ## When not to use - An internal-only change with no user impact. Update internal docs; do not announce. - The release is incomplete (still in active development). Wait until it ships, even if marketing wants the post. ## Determine the audience and channel first | Audience | Best channel | Tone | |---|---|---| | Existing power users | Changelog, in-app note | Terse, factual, links | | Engineering teams adopting your API | Release notes, dev blog | Examples, migration steps, version pins | | Prospective customers | Landing page, marketing blog | Story arc, problem → solution, social proof | | Broad audience | Social post, email newsletter | One-sentence pitch, link to depth | | Internal team | Slack/Discord post | What changed, who to ping if it breaks | Pick the audience for *this* writeup. One release often needs several writeups; do not blend them. ## Universal structure Whatever the channel, lead with: 1. **What changed.** One sentence in the u...