release-announcement

Lead with what changed in one sentence, name who it affects, and state what the reader must do. Then pick the channel template: terse changelog entry, release notes with migration guide, dev blog post, in-app note, or social post.

A changelog entry is terse and factual, grouped under Added, Changed, Fixed, Deprecated, and Breaking headings. A dev blog post runs 300-800 words with a problem hook, feature examples with code or screenshots, upgrade steps, and a brief outlook.

Mark breaking changes with a "**Breaking:**" prefix in the changelog, include a migration guide with before/after code in the release notes, and repeat the warning in email and social channels so users see it before upgrading.

Skip announcements for internal-only changes with no user impact and for releases still in active development. Update internal docs instead, and wait until the release actually ships before publishing any public writeup.

Yes, when running inside Todero with experimental.enableCases enabled, it upserts release, blog post, and tweet storm cases and writes the copy as case documents. If the API returns 403 Cases are disabled, it reports the limitation and continues with the copy.