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。版本线状态首个版本发布进入 Active进入 MaintenanceEnd of lifemainunstable不稳定unstableunstableunstableunstablev9End of life2018-06-042018-06-042019-03-292022-03-31v10End of life2019-03-292019-03-292022-03-312024-09-30v11Active活跃2021-08-062022-03-31TBDTBDv12Preview预览2023-05-25TBDTBDTBD从表中可以看到几条重要线索main分支永远标记为 unstable每天合入main的代码都被视为不稳定消费者不应直接依赖main上的快照行为v9 与 v10 已全部 End of lifev10 的 EOL 为 2024-09-30这与 docs/release.md 中v10 于 2024 年 9 月 30 日停止所有代码与资产支持的描述一致v11 当前处于 Active 阶段初始发布 2021-08-062022-03-31 进入 Active后续日期待定TBDv12 处于 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 还是 majordocs/guides/versioning.md 给出了carbon/react的完整对照表例如组件 typings/definitions 变更 →patch新增组件 prop →minor移除已有 prop →majorprop 类型收窄如PropTypes.node→PropTypes.string→majorprop 类型放宽如PropTypes.string→PropTypes.node→minorPropTypes.func回调参数减少 →major参数增加 →minorrepo 佐证仓库 lerna.json 采用version: independent独立版本模式npmClient为 yarnversion 命令提交信息为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 supportLTS为无法频繁升级的产品兜底定义LTS 是附加给部分选定主版本的扩展支持标识。并非每个主版本都会成为 LTS。目标受众交付模型不允许定期升级到最新 Carbon 主版本的产品尤其是本地部署on-premises产品及服务本地部署客户的产品。这类项目通常有一段集中的功能开发期随后是漫长的维护期期间升级 Carbon 困难或不现实。支持内容LTS 版本接收与 Maintenance 相同的修复类型安全补丁、关键 bug 修复、以及在有明确需求时请求的非关键修复核心差异在于支持的时长与意图。无固定截止日Carbon 团队不会在指定 LTS 时武断地设定一个截止日期而是只要受支持的产品与客户对该版本线存在既定的业务需求就持续维护其发布基础设施并考虑请求的修复。边界澄清重要LTS不包含持续的功能开发也不应被当作可以不升级的替代方案。当升级可行时消费者仍应采纳当前 Active 版本。LTS 的目的纯粹是保障无法跟上 Carbon 标准发布节奏的产品的稳定性与可用性。三、Feature FlagsPreview 阶段的落地机制Preview 阶段之所以能以当前 Active 版本承载下一代变化靠的是仓库内置的特性开关体系。相关权威清单见 docs/feature-flags.md机器可读的完整清单见 packages/feature-flags/feature-flags.yml。3.1 两级命名约定enable-*前缀包含希望消费项目测试并反馈的新特性通常稳定、不太可能变化但仍可能根据反馈调整例如enable-dialog-element、enable-presence、enable-treeview-controllableenable-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子组件改为MenuItemMenuItemDivideritemText变为label删除项用kinddangerTile 默认图标ClickableTile无自定义图标时自动渲染ArrowRight禁用态渲染Error图标Pagination 预览 API 移除unstable_Pagination/preview_Pagination及unstable_PageSelector/preview_PageSelector被移除改用稳定版PaginationSass 视觉变化Tag 从胶囊形改为按尺寸取$border-radius-02/$border-radius-04Popover/Toggletip/Tooltip 移除 caret 并新增 4px 间距Toggle 标签与控件间距从$spacing-05收窄到$spacing-03。迁移加速器部分 flag 提供了 codemod通过carbon/upgrade执行npx carbon/upgrade migrate enable-v12-overflowmenu --writeWeb 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/reactReact 组件库对应仓库 packages/reactcarbon/web-componentsWeb Components 组件库对应 packages/web-componentscarbon/styles样式包对应 packages/stylescarbonmonorepo 内的所有其他包如 packages/feature-flags、packages/utilities、packages/icons 等carbon/ibm-productscarbon/ibm-products-web-components此外计划还覆盖carbon-website与carbon-design-kit仓库中的所有设计指南与设计工具包资产如 Figma 设计资源等。六、对消费者的综合行动建议综合 docs/release-schedule.md 与配套文档可以提炼出如下可执行策略跟随 Active生产项目应始终以当前 Active 版本线现在是 v11为基线每两周的 minor 更新可放心升级——docs/guides/versioning.md 保证 minor/patch 不破坏兼容性利用 Preview 窗口做渐进迁移升级 v12 不必等大版本落地。逐个开启enable-v12-*flag 并配合 codemod 迁移让每个变更独立验证若在 v12 发布前已全部开启升级时受影响组件将零改动为 EOL 预留时间注意版本线转入 Maintenance开始迁移与 EOL彻底失去支持两个节点v10 已于 2024-09-30 EOL不要继续在其上构建新功能关注无障碍与安全Maintenance 线不再跟进新 ruleset安全与关键修复仅在维护线中以 patch 形式提供如需最高的无障碍合规保持跟随 Active只有确有需要才考虑 LTSLTS 不提供功能开发仅适用于无法跟随标准节奏的本地部署类产品且以既有业务需求存在为持续支持的前提。七、延伸阅读仓库内资源docs/release-schedule.md本文章主体发布排期与阶段定义的权威来源docs/release.mdCarbon 团队在 monorepo 内发布各包的具体流程prerelease、stable、manual patch 等docs/guides/versioning.md各类型变更对应的 semver 级别对照表docs/feature-flags.mdflag 名称、包可用性与 codemod 关联的权威清单docs/migration/v12.md从 v11 迁移到 v12 的按包消费者影响清单packages/feature-flags/feature-flags.yml全部 flag 的机器可读清单packages/feature-flags/src/FeatureFlagScope.tsenable-v12-release动态短路所有 v12 flag 的实现源码achecker.js无障碍自动化测试的accessibility-checker配置lerna.jsonmonorepo 独立版本模式的发布工具配置【免费下载链接】carbonA design system built by IBM项目地址: https://gitcode.com/GitHub_Trending/carbo/carbon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考