Announcing the Carbon Design System Release Schedule

Taylor Jones
Published in
5 min readMay 12


Today we’re publishing a release schedule outlining the plan for previous, current, and future major versions of the Carbon Design System.

An illustration of two overlapping staircases with a person standing on the floor looking leftwards towards a series of stacked rectangles vaguely representing user interface elements. Another person at the top of one set of stairs looks rightwards towards another series of stacked rectangles that vaguely represent user interface elements. A large clock sits in the top left corner.

A long time coming

Since the release of v11 in March of last year, there have been a lot of questions and feedback around the timeline for both v10 and v11. As the ecosystem around the Carbon Design System continues to mature and grow, we’d like to begin setting expectations for the timeframe around each major release we publish.

Over the past few months we have engaged with many teams within IBM on this topic. We consulted with both early v11 adopters and those still using v10 to help determine a realistic and reasonable time window for support of major versions. It was clear from very early on that due to the scale of IBMs teams and operations there is a strong need for our versions to have a plan of long term support.

The plan

We’ve landed on a release schedule we believe reflects the realities of enterprise product development while also balancing the finite resources of teams working to grow and maintain the Carbon Design System ecosystem.

A chart showing the timeline for v9, v10, v11, and v12 carbon releases

Release phases

In this plan, each major release has three phases; Prerelease, Active and Maintenance.


The prerelease phase is intended to be the opportunity for early adopters, library authors, and other strategic ecosystem partners to begin to evaluate and integrate new changes into their codebases. For v11, this phase was eight months long and spanned four prerelease/beta releases. We hope to extend this timeframe even further for our next major.


A release in the Active phase receives biweekly minor releases containing new features and fixes. The work we deliver into main every day is considered unstable. Every two weeks we package up these changes into a new minor version that is published from main to the current Active major. Consuming projects should always aim to follow the Active release.


For a release in the Maintenance phase, patch releases are published containing security patches and critical bug fixes. When a version moves from Active to Maintenance, consuming projects should begin migrating to the new Active major version.

During Maintenance we also consider adding non-critical bug fixes on an ad hoc basis, by request only. This model has been working well for v10 so far and a number of fixes have already been back-ported from v11 to v10. If you’re using v10 and there is a v11 fix you’d like to see in v10, please open an issue.

Major timelines

v9 and v10

The release of v11 ushered in two changes — v9 no longer being supported, and the transition of v10 to the Maintenance phase. As shown in the plan, the v10 release will continue to be supported by our team through September of 2024.

This timeframe intentionally aligns with the fall planning period many teams have, and provides over 16 months to plan and accomplish a migration to v11. To help support this timeframe we are also actively working to reduce the time it takes to migrate to v11.


For the current major version, v11, it is in active development. All new features and fixes go here and are released biweekly in new minor versions. We anticipate moving v11 to Maintenance when v12 is released.

The future and beyond

Our next major version v12 is not quite in view yet, the timeline outlined in the chart is just an ideal proposal.

We’re currently ideating on ways that we could accelerate this release schedule without impacting teams. The next major version will be an opportunity to explore different approaches to change management and breaking changes to improve overall stability of our packages. There will be more on this to come, but ultimately we want our next major to be even more seamless from a migration standpoint.

What does this plan cover?

For now this plan covers the design and development assets under maintenance of the Carbon Design System core team. This includes the @carbon/react and @carbon/styles packages, as well as all other packages within the carbon monorepo. Soon we will provide more scoped information for @carbon/charts and @carbon/web-components. This plan also includes all design guidance and design kit assets (Figma, etc.) present on

The broader open-source Carbon Design System ecosystem is a complex array of assets spanning across multiple teams and library maintainers both inside and outside of IBM. This release plan may not map 1:1 for all these instances. We’ll work with library and framework variant authors to help establish how their release plans can ladder up into this plan. Ultimately we want the entire ecosystem to be in lockstep with one another and avoid fragmentation where possible. If you’d like to discuss plans for an asset or library you maintain, please reach out!

A living document, subject to change

We know this plan is the result of feedback from only a snapshot in time and we anticipate that the needs for version support will change over time. Ultimately, the dates and phases outlined in the release schedule are subject to change.

The plan will live in the carbon GitHub repository and future changes will be made there. If you have thoughts or concerns on any of this, we’d love to get your feedback and start a dialog in the GitHub discussion for this topic. This crucial feedback from the Carbon community will help guide future changes to this plan. Thank you again to the many teams that already helped to inform this work so far!

Taylor Jones is a Software Engineer based out of Austin, TX working on the Carbon Design System. The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.

Questions or comments about Carbon? Reach out at or tweet us @_carbondesign.



Taylor Jones

Front End Engineer @IBM, lemonade enthusiast, creator of things on the web.