The release communication checklist: everything to update when you ship

The code is merged, the deploy is green, the feature works. The release is not done. A release is done when the people it affects can find out — the user who asked for the feature, the developer whose script it changes, the support agent about to field questions about it, the prospect whose objection it just answered. All of that is communication work, and it is spread across a dozen small surfaces that are individually trivial and collectively always forgotten.

Which is why this is checklist territory. Release day is precisely when nobody has spare attention — you are watching dashboards, not remembering that the docs still describe the old behavior. Aviation solved this problem decades ago: you don’t rely on memory for routine-but-critical steps, you run the list. This guide is that list for shipping software: what to update before, at, and after a release, how to scale it so a Tuesday bugfix doesn’t get a product launch’s ceremony, and how to keep the checklist itself from decaying into theater.

One canonical entry; everything else points at it

Before the list: the structural rule that makes every row cheaper. Each release gets one canonical write-up at one URL — for most teams, the changelog entry — and every other surface excerpts it and links back. The email teases it, the tweet points at it, the in-app widget renders it, support pastes it into tickets. This is the one-canonical-URL rule, and it converts the checklist from “write eight different announcements” into “write one, then distribute it” — which is the difference between a checklist a team actually runs and one it quietly abandons.

Before the release

Most release-day scrambles are things that could have been done at merge time. The before-list:

  • Draft the changelog entry when the work merges, not when the deploy finishes. The details are freshest, the author is still assigned, and release day becomes a publish button instead of a writing task. Park it as a draft or schedule it from CI.
  • Update the docs so they can ship together. A feature that’s live while the docs describe the old behavior generates a support ticket per confused reader. Docs and changelog cover different tenses of the same change; the entry should link the exact docs section, which means the section has to exist first.
  • Write the migration guide if anything breaks. For a breaking change, the announcement cycle started weeks ago (or should have); release day is the last checkpoint, not the first warning.
  • Capture screenshots and GIFs on staging. Visual changes need pictures in the announcement, and the calm moment to capture them is before the release, not while users are already asking what moved.
  • Queue translations. If you ship release notes in multiple languages, translators need the source text days before the release — write-at-merge is what buys them that lead time.
  • Brief support and sales. Support learns about the release before users do, or users teach them. A two-line heads-up — what’s changing, what might confuse people, link to the draft entry — plus an updated support macro for the likely question is usually enough. Sales gets the one-liner for the prospect who asked for exactly this.
  • Decide the announcement tier now (see “scale the list” below), so release day executes a plan instead of debating one.

At release

The iron rule of timing: announce when the reader can actually use it — not when the code deploys behind a flag, and not three days after the rollout finished. For staged rollouts, that usually means scheduling the announcement for when availability is real. The at-release list:

  • Publish the canonical entry. If your changelog has feeds, subscribers — human and script — are now notified without another keystroke. This row is the floor: it runs for every release, including the ones where it’s the only row.
  • Let the in-app surface pick it up. A what’s-new widget that reads your changelog turns the publish into in-product reach automatically — zero marginal work, which is the point of wiring it up once.
  • Mirror to community chat. The Discord/Slack post is a pointer — title, one line, permalink — not a second copy that can drift.
  • Update store listings if you ship through one. App store “What’s New” fields have their own character limits and review clocks; the store text is a teaser cut from the canonical entry, written before submission.
  • Flip the API-facing signals for API changes. Deprecation headers, OpenAPI spec, SDK release notes — the API changelog discipline has its own list, and “the humans were told” doesn’t cover the scripts.

After the release

  • Send email only if this release earns it. Email is the most intrusive channel; launch-grade features, breaking changes, and security fixes qualify — the routine Tuesday release does not. Sending it a few hours after the changelog entry, not simultaneously, means the link has been soak-tested by less intrusive channels first.
  • Post social pointing at the canonical URL — and if the release deserves narrative (the why, the design story), that’s a blog post that links the entry, not a longer changelog entry.
  • Close the loop with the people who asked. The reporter of the bug you fixed and the requester of the feature you shipped are the highest-value readers the release has. A one-line reply on the original ticket with the permalink converts “shipped” into “they listened.”
  • Update the roadmap. If the feature was on a public roadmap, move it to shipped — a roadmap that still lists a delivered feature as “next” is quietly telling readers the roadmap is fiction.
  • Watch what the announcement did. Not applause — first use of the feature, ticket deflection, migration curves. That’s also how you learn which checklist rows are earning their place.

Scale the list to the release

Running the full list for every release is how checklists die. Tier by user impact, not engineering effort — the six-week refactor that changes nothing visible gets less ceremony than the one-line fix for the bug users hit daily:

  • Tier 3 — routine. Bugfixes, small improvements. The changelog entry is the checklist; feeds and widget fan out automatically. Thirty seconds of communication work, total.
  • Tier 2 — notable. Features some users will care about. Entry + chat mirror + support heads-up; maybe a social post. No email.
  • Tier 1 — launch-grade. Features that change why people pick the product, and anything breaking. The full list, including email and the blog narrative.

The floor never drops below the entry itself: a release too small to announce anywhere still goes in the changelog, because the changelog’s value is completeness — it’s the one place a reader can trust that if it shipped, it’s there.

Special releases override the default list

Four kinds of release come with their own protocol — when one applies, its rules outrank this list:

The checklist

BEFORE (at merge / days ahead)
[ ] Changelog entry drafted (draft or scheduled publish)
[ ] Docs updated, ready to ship with the release
[ ] Breaking? Migration guide written, deprecation cycle already run
[ ] Screenshots / GIFs captured on staging
[ ] Translations queued (if you localize)
[ ] Support + sales briefed; support macro updated
[ ] Announcement tier decided (1 / 2 / 3)

AT RELEASE (when users can actually use it)
[ ] Publish the canonical changelog entry  ← the floor: every release
[ ] Feeds + in-app widget fan out (automatic if wired)
[ ] Chat mirror posted: title + one line + permalink
[ ] Store listing text updated (if applicable)
[ ] API signals flipped: headers, spec, SDK notes (if API-facing)

AFTER (same day / next day)
[ ] Email — only if tier 1
[ ] Social post → canonical URL; blog if the release earns narrative
[ ] Reply to the tickets/requests this release resolves, with permalink
[ ] Public roadmap updated
[ ] Metrics check within the week: first use, ticket deflection

Tier 3 releases run three of these rows. That’s not cutting corners — that’s the tiering working.

Keeping the checklist alive

A checklist on a wiki page is where release process goes to die. The one that survives lives inside the release workflow — checkboxes in the release pull-request template or the release ticket, so it’s in front of whoever ships, every time, without anyone remembering to go look at it.

Three maintenance rules. First, automate rows out of the list: wiring the widget and feeds made in-app fan-out free; a CI step that drafts the entry makes “entry drafted” nearly free; every automated row is one fewer thing release day can forget. Second, give the list an owner per release — a rotating name attached to “the list got run,” because a checklist owned by everyone is owned by no one. Third, prune quarterly: a row nobody has executed in six releases is either a candidate for automation or for deletion — dead rows train people to skim, and a skimmed checklist protects nothing.

Anti-patterns

  • Checklist theater. Boxes ticked, work not done — the docs box checked because someone opened the docs. The fix is making rows verifiable: “docs updated” becomes “entry links the updated docs section.”
  • Announcing before it’s usable. The blog post is live, the rollout is at 10%. Ninety percent of readers just clicked into a feature they don’t have — schedule the announcement for availability, not for the deploy.
  • The hero release manager. The full list lives in one person’s head and their releases go beautifully — until they’re on vacation. If it isn’t written down where releases happen, it isn’t a process; it’s a person.
  • “Docs will catch up later.” Later is measured in support tickets. If the docs genuinely can’t ship same-day, the entry says so — honesty about the gap beats pretending it isn’t there.
  • Full fanfare for every release. Email for every bugfix burns the one channel that reaches dormant users; by the release that matters, everyone unsubscribed. Tiering is what keeps tier-1 channels loud.
  • Eight hand-written announcements. Each channel gets its own prose, the versions drift, and the email promises what the docs walk back. One canonical entry, many excerpts — the channels differ in shape, not in facts.

Doing this with Wakelog

Wakelog is built to be the canonical-entry row of this list — and to make the fan-out rows free. Draft the entry from CI at merge time (draft=true via the API, or the CLI’s --from-git --draft), schedule it with publish_at so the announcement lands when the rollout is real, and one publish fans out to the RSS/JSON feeds, the embeddable what’s-new widget, and per-project Discord/Slack webhooks in the same motion. Every entry gets a stable permalink — the URL the support macro, the ticket reply, and the social post all point at. Honest caveat: Wakelog deliberately doesn’t send email or post to social for you — those rows, and the judgment about which releases earn them, stay yours.

Make the canonical entry the easy row   Next: how to announce a new feature →

Related guides

Last updated 2026-07-31 · All guides