Release cadence: how often should you ship?

"How often should we release?" is really two questions wearing one trenchcoat: how often you deploy, and how often you tell people what changed. Teams that conflate them end up either spamming users with every deploy or shipping silently for months. This guide splits them apart and gives you defaults for each.

Deploy cadence: as often as your safety net allows

For deploys, faster is almost mechanically better. Small batches mean small diffs, small blast radius, easy rollbacks, and less "merge day" dread. The ceiling isn't courage — it's infrastructure: tests you trust, one-command rollback, and monitoring that tells you within minutes if something broke. If you have those, deploy on every merge. If you don't, that's the actual problem to fix; slowing down just makes each release scarier.

The classic failure mode of slow deploys is the release train pile-up: six weeks of changes land at once, something breaks, and nobody can tell which of the 40 commits did it. Cadence didn't cause the bug — batching caused the debugging.

Announcement cadence: as often as users can notice

Announcements have the opposite economics. Every deploy is free to make; every announcement spends attention, and attention is the scarcest thing your users give you. Announce every deploy and people unsubscribe; announce twice a year and they assume the product is dead.

Useful defaults by product type:

  • Developer tools & libraries — announce per release (that's what versions are for), batch trivial patches. Your users actively check before upgrading; they want the granularity.
  • SaaS products — weekly to monthly. A dated stream of "what's new" entries, each one user-visible. Internal refactors don't get entries.
  • Early-stage / building in public — weekly, even when small. The changelog doubles as proof of life; momentum is the product.

The test for whether something deserves an entry: could a user notice this without being told? If yes, announce it. If no (refactor, dependency bump, infra), it can wait for an occasional "under the hood" roundup.

The two failure modes

  • Too fast (the firehose): every commit becomes a post, users learn to skim, then to skip. Fix: batch small fixes into one weekly entry with bullets; keep tags honest so scanners can filter.
  • Too slow (the dead changelog): last entry eight months ago reads as "abandoned" — even when you shipped constantly. Fix: a floor, not a ceiling. Decide the longest silence you'll allow (a month is a good default) and post a short "still here — this month was infrastructure" note if nothing user-visible shipped.

Cadence is a promise — make it cheap to keep

Whatever rhythm you pick, the thing that kills it is never the decision — it's the chore. If announcing means "open the CMS, write copy, find a screenshot, ping marketing", it will lose to whatever else is on fire. The fix is structural, the same as with tests and deploys: put the announcement inside the release flow.

  • End your release script with a post: tag, deploy, announce — one script.
  • Mirror GitHub/GitLab releases to your public changelog with a webhook, so announcing is a side effect of releasing.
  • Draft entries ahead and schedule them for the release moment, so announcement day is a no-op.

Wakelog is built around exactly this: git tag v1.4 && wakelog post --from-git posts the entry from your terminal, release webhooks mirror GitHub/GitLab releases automatically, and scheduled publishing lets you write Tuesday's announcement on Friday. The cadence you choose becomes the cadence you keep.

Start a changelog — free   Next: how to write a changelog →

Related guides

Last updated 2026-07-26 · All guides