Toolbox

Monthly release cadence

Ship on a monthly release train teams can plan around: 22 checks, a calendar generator with .ics, a changeset gate and Changesets 3 config.

What it is

Field Guide 08: a 22-item guide to running a design system on a monthly release train with majors only in April and October. The kit computes the calendar from a rule (second Tuesday, freeze five working days earlier, RFC cut-off before that) and exports it as a 36-event .ics file, gates changesets against the train they ship in, and includes a Changesets 3 config verified with @changesets/cli 3.0.3, a release checklist and a release notes template.

When to use

When product teams are surprised by releases, breaking changes arrive at random, or urgent hotfixes keep skipping review.

How to use

Edit release-train.json: rule, freeze length, major months and your own holidays
Run node scripts/release-calendar.mjs for next year and publish the .ics file
Copy .changeset/config.json into your monorepo and require a changeset per package change
Run node scripts/check-changesets.mjs .changeset --train YYYY.MM in CI before each freeze
Copy RELEASE-CHECKLIST.md into each train's tracking issue and post notes from CHANGELOG.template.md

Before you start

Prerequisites and when to skip this.

Prerequisites

Versioned packages that consumers install by semver range
Node 22.11 or later for Changesets 3 (the kit's own scripts need Node 20)

When NOT to use this

A system consumed only from a single application repository at head
Pre-1.0 packages where anything may change in any release

Consider instead

Consumers want fixes faster than monthly: Keep the monthly train for minors and majors, and ship reviewed patches out of train

Downloads

Guide (PDF)Full kit (ZIP): PDF, HTML, Markdown, calendar, gate, config, checklist

One-page RFC templateDeprecation policy with datesEnterprise UX that ships

The share link includes source tracking so LinkedIn traffic stays measurable in analytics.

Share on LinkedIn