Carbon Design System 发布周期全解析：从 v9 到 v12 的版本演进、支持阶段与维护策略

Carbon Design System 发布周期全解析：从 v9 到 v12 的版本演进、支持阶段与维护策略

【免费下载链接】carbonA design system built by IBM项目地址: https://gitcode.com/GitHub_Trending/carbo/carbon

本指南基于 IBM Carbon Design System 官方文档 docs/release-schedule.md 编写，系统讲解该设计系统从 v9 到 v12 的版本时间线、五大发布阶段（Preview、Prerelease、Active、Maintenance、LTS）的定义与消费方应对策略，并深入仓库源码说明 Feature Flags 机制、无障碍合规测试与受管资源范围。读完本文，你将能够判断当前应跟随哪个版本线、如何规划升级窗口，以及如何利用enable-v12-*特性开关平滑迁移到 v12。

一、这是一份"活的文档"：发布计划总览

docs/release-schedule.md是一份持续更新（living document）的文档，它不承诺固定不变的日期，而是描述 Carbon Design System 既往、当前与未来各个主版本（major version）的支持计划。核心信息以一张状态表呈现，同时明确"日期随时可能调整（Dates are subject to change）"。

从表中可以看到几条重要线索：

• main分支永远标记为 unstable：每天合入main的代码都被视为不稳定，消费者不应直接依赖main上的快照行为；
• v9 与 v10 已全部 End of life：v10 的 EOL 为 2024-09-30，这与 docs/release.md 中"v10 于 2024 年 9 月 30 日停止所有代码与资产支持"的描述一致；
• v11 当前处于 Active 阶段，初始发布 2021-08-06，2022-03-31 进入 Active，后续日期待定（TBD）；
• v12 处于 Preview 阶段，自 2023-05-25 起开始以特性开关形式预演，何时转正待定。

这一发布模型并非 Carbon 原创——文档明确致谢了 NodeJS Release Working Group 的工作，其排期图也基于nodejs/lts-schedule的 fork 生成（见 docs/release-schedule.md 的 Acknowledgements 一节）。它本质上是一套面向"设计系统这类需要长期被产品依赖的库"的受控演进框架。

二、五大发布阶段：定义与消费者行动指南

发布计划的核心是把一条版本线的一生划分为五个阶段，每个阶段对应不同的更新频率、支持强度和消费者应对方式。

2.1 Preview（预览）：通过特性开关渐进式尝鲜

定义：当第一个 feature flag 被"承诺（committed）"将在未来某个主版本中默认开启时，该未来主版本便进入 Preview 阶段。消费者可以在当前 Active 版本内增量选择开启那些属于下一代的变化，而不必等待整个大版本发布。

关键机制——flag 命名约定：一旦某个 flag 被承诺，其名称就会带上承诺的目标版本号，前缀为enable-v#-*，例如enable-v12-tile-default-icons。此时 flag 背后的 API 或功能行为即被"冻结（fixed）"，不会再改变；Carbon 团队计划在名称中标明的那个主版本中将其默认开启。

消费者收益（文档原话）：理论上，如果在 v12 发布前你的项目已启用了所有enable-v12-*特性开关，那么升级到 v12 时，受影响组件将无需再做任何改动。这正是 Preview 阶段的价值——把一次大版本升级的"大爆炸"拆解为可独立验证、可自主掌控节奏的小步迁移。

2.2 Prerelease（预发布）：给早期采用者与生态伙伴的集成窗口

定义：Prerelease 阶段为早期采用者、库作者和战略生态伙伴提供提前评估与集成新变化的机会。

事实参考：文档指出 v11 的 Prerelease 阶段长达八个月，跨越了四个 prerelease/beta 版本；Carbon 团队希望下一个主版本（v12）将这个时间窗进一步拉长。

配套流程：在 docs/release.md 中可以找到具体的预发布节奏——每个 minor 稳定版发布前几天，会先发布一次 prerelease（例如v11.2.0-rc.0），为产品在稳定版发布前提供集成测试窗口；release 团队在 sprint 最后一周的周一通过 Version Workflow 指定preminor生成 prerelease 版本号，后续追加则使用prerelease（如v11.12.0-rc.0→v11.12.0-rc.1）。

2.3 Active（活跃）：消费项目应始终跟随的版本线

定义：Active 是"官方建议消费项目跟随"的阶段，也是 docs/release-schedule.md 中明确要求的方向——"Consuming projects should always aim to follow the Active release"。

更新频率：Active 阶段每两周（biweekly）发布一次 minor 版本，包含新特性与修复。其工作流为：团队每天向main交付代码（unstable）→ 每两周将这批变更打包为一个新的 minor 版本，从main发布到当前 Active 主版本。

配套版本语义：什么改动对应 patch、minor 还是 major？docs/guides/versioning.md 给出了@carbon/react的完整对照表，例如：

• 组件 typings/definitions 变更 →patch
• 新增组件 prop →minor
• 移除已有 prop →major
• prop 类型收窄（如PropTypes.node→PropTypes.string）→major
• prop 类型放宽（如PropTypes.string→PropTypes.node）→minor
• PropTypes.func回调参数减少 →major，参数增加 →minor

repo 佐证：仓库 lerna.json 采用"version": "independent"独立版本模式，npmClient为 yarn，version 命令提交信息为chore(release): %s，这与 docs/release.md 中所有发布提交均以chore(release): vX.Y.Z命名的方式完全吻合，也从侧面印证了"从main定期切出版本"这一发布模型在 monorepo 工具链上的落地。

2.4 Maintenance（维护）：安全补丁与关键缺陷修复

定义：进入 Maintenance 的版本线只发布补丁版本，内容限于安全补丁和关键 bug 修复。

消费者义务：当版本从 Active 转入 Maintenance，消费项目应开始迁移到新的 Active 主版本。

非关键修复的请求方式：Maintenance 期间，团队会按需（ad hoc）考虑加入非关键 bug 修复，但仅限请求制（by request only）——需要提交 issue 并附上对应 v11 修复 PR 的链接。

例外情形：关键安全与 bug 修复可能需要在某条 release 流中引入 semver-major 级别的变化，这种情况很少见，且会以 semver-minor 形式落地，同时必须包含回退（revert）选项。

术语约定：文档定义一个专门术语"supported release lines"（受支持的版本线），指所有未进入 End-of-Life 的版本线。

2.5 Long-term support（LTS）：为无法频繁升级的产品兜底

定义：LTS 是附加给部分选定主版本的扩展支持标识。并非每个主版本都会成为 LTS。

目标受众：交付模型不允许定期升级到最新 Carbon 主版本的产品，尤其是本地部署（on-premises）产品及服务本地部署客户的产品。这类项目通常有一段集中的功能开发期，随后是漫长的维护期，期间升级 Carbon 困难或不现实。

支持内容：LTS 版本接收与 Maintenance 相同的修复类型（安全补丁、关键 bug 修复、以及在有明确需求时请求的非关键修复），核心差异在于支持的时长与意图。

无固定截止日：Carbon 团队不会在指定 LTS 时武断地设定一个截止日期，而是只要受支持的产品与客户对该版本线存在既定的业务需求，就持续维护其发布基础设施并考虑请求的修复。

边界澄清（重要）：LTS不包含持续的功能开发，也不应被当作"可以不升级"的替代方案。当升级可行时，消费者仍应采纳当前 Active 版本。LTS 的目的纯粹是保障无法跟上 Carbon 标准发布节奏的产品的稳定性与可用性。

三、Feature Flags：Preview 阶段的落地机制

Preview 阶段之所以能"以当前 Active 版本承载下一代变化"，靠的是仓库内置的特性开关体系。相关权威清单见 docs/feature-flags.md，机器可读的完整清单见 packages/feature-flags/feature-flags.yml。

3.1 两级命名约定

• enable-*前缀：包含希望消费项目测试并反馈的新特性，通常稳定、不太可能变化，但仍可能根据反馈调整，例如enable-dialog-element、enable-presence、enable-treeview-controllable；
• enable-v#-*前缀：已被"承诺"到某个未来主版本的稳定特性，API/行为冻结不再变化，将随名称中的主版本默认开启，例如enable-v12-tile-default-icons、enable-v12-overflowmenu、enable-v12-dynamic-floating-styles。仓库 packages/feature-flags/feature-flags.yml 中enable-v12-*系列 flag 默认全部为false（除enable-v11-release为true外）。

承诺（commit）一个 flag 到enable-v#-*的前提条件（摘自 docs/feature-flags.md）：经过早期采用者测试、在 Unit/AVT/VRT 测试中完全覆盖、在 Storybook 与官网文档中记录、在可能的情况下提供自动化迁移脚本（codemod）。

3.2enable-v12-release：一键开启全部 v12 行为

packages/feature-flags/src/FeatureFlagScope.ts 的源码揭示了开关的底层语义：

• 定义了v12ReleaseFlag = 'enable-v12-release'与前缀enable-v12-；
• isV12Flag(name)判断一个 flag 是否属于 v12 默认行为——条件是不等于enable-v12-release自身，且要么以enable-v12-开头，要么位于一个特殊的"无前缀 v12 flag"集合unprefixedV12Flags = new Set(['enable-focus-wrap-without-sentinels'])中。源码注释说明：这个集合与 Sass 侧index.scss中的$unprefixed-v12-flags需保持同步，否则会出现"JS 里是 v12 行为而 Sass 里不是"的不一致；
• enabled(name)方法在查询时做核心判断：如果该 flag 是 v12 flag 且enable-v12-release已开启，则直接返回true，否则返回该 flag 自身的值（默认false）。

也就是说，enable-v12-release并非物理地修改每个 flag 的值，而是在读取时动态短路所有enable-v12-*flag——这正是"启用一个开关即可预览整个 v12 行为面"的实现原理。

3.3 消费者如何使用

在 v11 项目中按需开启（以 React 为例，各框架配置方式见对应包的文档与 Storybook）：

// 以特性开关包裹应用 import { FeatureFlags } from '@carbon/react'; <FeatureFlags flags={{ 'enable-v12-overflowmenu': true }}> <App /> </FeatureFlags>

或直接开启全部 v12 行为：

<FeatureFlags flags={{ 'enable-v12-release': true }}> <App /> </FeatureFlags>

开启后，docs/migration/v12.md 提供了按包组织的消费者影响清单，例如：

• OverflowMenu 组合方式变更：OverflowMenuItem子组件改为MenuItem+MenuItemDivider，itemText变为label，删除项用kind="danger"；
• Tile 默认图标：ClickableTile无自定义图标时自动渲染ArrowRight，禁用态渲染Error图标；
• Pagination 预览 API 移除：unstable_Pagination/preview_Pagination及unstable_PageSelector/preview_PageSelector被移除，改用稳定版Pagination；
• Sass 视觉变化：Tag 从"胶囊形"改为按尺寸取$border-radius-02/$border-radius-04；Popover/Toggletip/Tooltip 移除 caret 并新增 4px 间距；Toggle 标签与控件间距从$spacing-05收窄到$spacing-03。

迁移加速器：部分 flag 提供了 codemod，通过@carbon/upgrade执行：

npx @carbon/upgrade migrate enable-v12-overflowmenu --write

Web Components 与 Sass 的迁移目前为手动操作（见 docs/feature-flags.md 的说明）。

四、无障碍（Accessibility）：随发布周期滚动演进

发布计划不仅管理功能，也管理无障碍合规。

4.1 Active 版本线的自动化测试

Active 版本线使用 IBMa 的accessibility-checker在真实浏览器环境中测试，覆盖默认组件状态、复杂/内部状态（如 open、focused 等）以及键盘导航流程，并采用当时最新的 ruleset。

repo 佐证：仓库根目录的 achecker.js 即为该工具的实际配置——ruleArchive: 'versioned'、failLevels: ['violation']，并在 CI 环境（process.env.CI）下额外上报 potentialviolation、recommendation、manual 级别；cacheFolder按JEST_WORKER_ID隔离以避免并行 worker 共享缓存，输出目录为.avt/reports。这与 e2e 目录下每个组件*-test.avt.e2e.js的自动化可访问性端到端测试文件一一对应。

4.2 Ruleset 是移动靶：合规会"过期"

文档强调：ruleset 是移动目标（moving target），随着新标准、新规则与新技术的出现，曾经完全合规的组件可能在新的 ruleset 下重新不合规。

v11 起的测试策略：测试只针对发布时点的最新 ruleset运行，版本不会在新旧 ruleset 上重新测试。文档举例：v11.35.0 于 2023-08-17 发布，当时的最新 ruleset 为August 09 2023 Deployment——该版本既不在更早的 ruleset 上测试过，也不会在更新的 ruleset 上测试。ruleset 及其部署日期可查询 IBM 无障碍网站。

4.3 消费者的现实建议

• 推荐保持跟随最新 Active 版本线，以获得最大的无障碍合规度，尤其是在新主版本发布后；
• Maintenance版本线不会针对更新的 ruleset 重新测试，使用维护版时可能出现无障碍缺口，需要自行修补或通过提交 PR 提供修复。

五、受本发布计划管理的资产范围

该发布计划覆盖 Carbon Design System 核心团队维护的设计与开发资产，包括：

• @carbon/react（React 组件库，对应仓库 packages/react）
• @carbon/web-components（Web Components 组件库，对应 packages/web-components）
• @carbon/styles（样式包，对应 packages/styles）
• carbonmonorepo 内的所有其他包（如 packages/feature-flags、packages/utilities、packages/icons 等）
• @carbon/ibm-products
• @carbon/ibm-products-web-components

此外，计划还覆盖carbon-website与carbon-design-kit仓库中的所有设计指南与设计工具包资产（如 Figma 设计资源等）。

六、对消费者的综合行动建议

综合 docs/release-schedule.md 与配套文档，可以提炼出如下可执行策略：

1. 跟随 Active：生产项目应始终以当前 Active 版本线（现在是 v11）为基线，每两周的 minor 更新可放心升级——docs/guides/versioning.md 保证 minor/patch 不破坏兼容性；
2. 利用 Preview 窗口做渐进迁移：升级 v12 不必等大版本落地。逐个开启enable-v12-*flag 并配合 codemod 迁移，让每个变更独立验证；若在 v12 发布前已全部开启，升级时受影响组件将零改动；
3. 为 EOL 预留时间：注意版本线转入 Maintenance（开始迁移）与 EOL（彻底失去支持）两个节点，v10 已于 2024-09-30 EOL，不要继续在其上构建新功能；
4. 关注无障碍与安全：Maintenance 线不再跟进新 ruleset，安全与关键修复仅在维护线中以 patch 形式提供；如需最高的无障碍合规，保持跟随 Active；
5. 只有确有需要才考虑 LTS：LTS 不提供功能开发，仅适用于无法跟随标准节奏的本地部署类产品，且以"既有业务需求存在"为持续支持的前提。

七、延伸阅读（仓库内资源）

• docs/release-schedule.md：本文章主体，发布排期与阶段定义的权威来源
• docs/release.md：Carbon 团队在 monorepo 内发布各包的具体流程（prerelease、stable、manual patch 等）
• docs/guides/versioning.md：各类型变更对应的 semver 级别对照表
• docs/feature-flags.md：flag 名称、包可用性与 codemod 关联的权威清单
• docs/migration/v12.md：从 v11 迁移到 v12 的按包消费者影响清单
• packages/feature-flags/feature-flags.yml：全部 flag 的机器可读清单
• packages/feature-flags/src/FeatureFlagScope.ts：enable-v12-release动态短路所有 v12 flag 的实现源码
• achecker.js：无障碍自动化测试的accessibility-checker配置
• lerna.json：monorepo 独立版本模式的发布工具配置

【免费下载链接】carbonA design system built by IBM项目地址: https://gitcode.com/GitHub_Trending/carbo/carbon