Release cadence for product teams
How GDS releases will be announced so EHQ and other products can plan upgrades with fewer surprises.
Design systems only help if product teams can adopt them on a predictable rhythm. This note sets expectations for how GDS releases will be communicated as more apps - including EHQ’s Admin UI, Blue Haven, and Bazaar - come on board.
What “a release” means
A GDS release is a published version of @granicus/gds-core on Granicus
Artifactory, with:
- version number and date
- summary of user-facing changes
- breaking changes called out explicitly
- links to docs / Storybook for anything new
How we will announce
| Channel | Role |
|---|---|
| Changelog | Version-by-version history from Changesets (package CHANGELOG.md) |
| News | Narrative release announcements when teams need context |
| Docs site | Updated component and foundation pages |
| Storybook | Interactive verification of the same bits |
| Slack / team channels | Heads-up for breaking or time-sensitive changes |
If it is not in News, assume it is not an official consumer-facing release note yet.
Cadence we are aiming for
Exact dates will settle as contribution volume grows. The working model:
- Patch - fixes and small polish; adopt when convenient
- Minor - new components or additive APIs; plan into a sprint
- Major - breaking changes; announce early with a migration path
We will prefer additive minors over surprise breaks. When a break is required, News will say what changed, who is affected, and the recommended upgrade steps.
What product teams should do
- Pin
@granicus/gds-coredeliberately (don’t float onlatestin production) - Review News before upgrading shared packages across multiple repos
- Smoke-test shell + one high-traffic form after each minor/major bump
- File gaps (missing components, token issues) with the GDS / design team instead of forking a second UI kit
Why this matters for EHQ
EHQ spreads UI work across several apps and historical libraries. A clear release cadence lets those teams upgrade in waves - shell first, then critical journeys - without each repo inventing its own update process.
See the adoption playbook for how releases fit into a longer migration.