仓颉社区版本出口标准:LTS与STS版本必须通过的11项质量指标详解
2026/9/24 14:35:40 网站建设 项目流程

仓颉社区版本出口标准:LTS与STS版本必须通过的11项质量指标详解

【免费下载链接】community包含Cangjie社区治理、开发者贡献指南、开发者贡献协议、社区交流等内容项目地址: https://gitcode.com/Cangjie/community

仓颉社区版本出口标准是仓颉语言社区为每次版本发布设立的质量"守门员"。本文详解 LTS 与 STS 版本必须通过的 11 项核心质量指标——从需求完成度、社区门禁、UT/ST 覆盖率到冒烟测试通过率、7×24 小时稳定性测试与 ABI 兼容性测试,帮助新手和普通用户快速看懂仓颉社区版本的质量门槛与发布规则。

📦 版本体系速览:先搞懂 LTS、STS 和 Nightly

在逐项拆解质量指标之前,先了解仓颉社区的版本分类。完整规则见 cangjie_pmc/version_management.md:

版本类型能力定位发布与维护周期质量定位
Nightly尝鲜版本,特性级尝鲜验证每日构建,发布件保留 1 个月仅基本功能验证,无兼容性保证
STS基本功能稳定,支持厂商联调间隔最长 6 个月,每年 3 月、9 月发布稳定版本,可能含未完全稳定的尝鲜特性
LTS功能稳定,支持三方厂商商业化集成2 年发布周期,3 年社区支持,每月补丁经过兼容性和长期稳定测试的稳定版本

版本号采用x.y.z约定:X代表 LTS 大版本,Y代表该 LTS 周期内的 STS 版本,Z用于补丁版本。例如 LTS1.0.0下的第一个 STS 版本号为1.1.0

💡 简单记忆:Nightly 每日尝鲜、STS 半年一更尝鲜新特性、LTS 两年一次长期可靠

✅ 11项核心质量指标总览:出口标准一览表

官方出口标准共定义了 13 个质量要求小类,其中 11 项是 STS 与 LTS 版本都必须通过的硬性质量指标,完整对照表见 cangjie_pmc/仓颉社区版本出口标准.md:

#质量指标NightlySTS 要求LTS 要求
1需求完成度NA规划内需求 100% 合入规划内需求 100% 合入
2社区门禁通过通过通过
3静态检查NA清零清零
4编译错误清零NA清零清零
5UT/ST 覆盖率基于前一天不劣化≥70%≥70%
6冒烟测试通过率>90%100%(含安装部署)100%(含安装部署)
7测试用例通过率NA>99%≥99%
8性能NA满足 STS 基线满足 LTS 基线
9稳定性NA通过 7×24 小时稳定性测试通过 7×24 小时稳定性测试
10ABI 兼容性NASTS 内兼容LTS 内兼容
11遗留问题NA无安全红线/关键阻塞问题无安全红线/关键阻塞问题

下面按类别逐组拆解这些仓颉版本质量指标。

🧩 指标 1~2:需求完成度与社区门禁——"东西齐了,门也要过"

  • 需求完成度:所有规划内需求必须 100% 合入。版本发布前,路线图上的功能一项都不能少。
  • 社区门禁:每日构建流水线中的 CI 门禁(PR 检测 → 联合构建 → 测试运行)必须全部通过,这是版本构建的第一道自动关卡。

🔍 指标 3~5:代码质量清零——静态检查、编译错误与测试覆盖率

  • 静态检查清零:包括代码规范检查、合规检查、安全检查报告等,正式版本要求问题"清零",Nightly 则不强制。
  • 编译错误清零:各平台编译不允许残留任何编译错误。
  • UT/ST 覆盖率:单元测试(UT)与系统测试(ST)覆盖率要求达到70%;Nightly 仅要求"相对前一天不劣化"。

🧪 指标 6~7:测试通过率——冒烟测试 100%,测试用例 99%+

  • 冒烟测试通过率 100%:覆盖安装、部署等最基础路径,正式版本不允许任何失败;Nightly 门槛相对宽松(>90%)。
  • 测试用例通过率:STS 要求 >99%,LTS 要求 ≥99%,保障版本整体功能可用。

⚡ 指标 8~9:性能与 7×24 小时稳定性测试

  • 性能基线:基于社区标准测试环境的性能规格,STS 满足 STS 基线,LTS 满足更高标准的 LTS 基线。
  • 稳定性测试:必须通过7×24 小时(一周不间断)稳定性测试,并包含 GC 压测与变压稳定性测试——这是长时运行不崩溃的关键保障。

🔗 指标 10~11:ABI 兼容性与遗留问题清零

  • ABI 兼容性:通过兼容性测试验证。规则是"版本族内兼容"——STS 各小版本间兼容、LTS 各补丁版本间兼容,但不同 LTS/STS 大版本之间不保证兼容,升级跨版本前请提前验证。
  • 遗留问题:发布前必须做到无安全红线问题、无关键阻塞问题、无严重影响开发体验的问题

🚪 另外两道出口关卡:升级兼容与资料测试

除 11 项硬性指标外,出口标准还有两类要求:

  • 升级(仅 LTS 强制):LTS 版本须通过升级测试,保证同一大版本族内可平滑升级;
  • 资料测试:Release Notes(RN)与用户手册均须通过文档测试,确保用户拿到版本时"资料与代码同步可信"。

🛡️ 标准如何落地:日常合入流程就在守护这些指标

出口标准不是发布前才检查的"突击考试",而是日常合入流程持续守护的结果。根据 cangjie_pmc/仓颉社区版本出口标准.md 对应的治理制度与 contribute/codemerge.md 的合入标准,每个 PR 需同时满足:

  1. 至少2 位开发者评审通过
  2. 至少1 位 Committer 审查通过
  3. CI 门禁通过(提交信息规范、代码构建、测试验证)。

仓库层面还通过 PR 审查人数限制与保护分支机制(dev/main 分支的推送和合入受权限管控)确保主分支稳定性:

📚 延伸阅读:从标准到参与贡献

  • 版本出口标准原文:cangjie_pmc/仓颉社区版本出口标准.md
  • 版本管理与版本号约定:cangjie_pmc/version_management.md
  • 版本路线图:cangjie_pmc/roadmap/roadmap_version.md
  • 代码合入标准:contribute/codemerge.md
  • 贡献指南:contribute/contribution.md

一句话总结:Nightly 管"尝鲜",STS/LTS 管"稳定"——11 项质量指标加升级与资料两道关卡,共同构成了仓颉社区版本从代码库走向用户手中的质量通行证。想要了解你的代码如何通过这些门禁,不妨从贡献指南开始,提交你的第一个 PR 试试!

【免费下载链接】community包含Cangjie社区治理、开发者贡献指南、开发者贡献协议、社区交流等内容项目地址: https://gitcode.com/Cangjie/community

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询