社区版本发布指导
1. 总则
本指导适用于社区内版本的发布评审工作，旨在规范发布流程、保障版本质量、明确评审权责。技术委员会（TC）为版本发布审核的责任主体，所有评审决策需遵循社区TC会议决策机制。
2. 发布前提
待发布版本需完成全量测试流程，且符合社区既定质量标准，同时提交完整的测试通过报告。
- 测试流程需覆盖单元测试、集成测试、系统测试及安全测试等核心环节
- 测试报告需参考测试报告模板编制，版本需满足社区定义的功能、性能、兼容性及安全基线要求
3. 发布审核组织
3.1 评审会议形式
版本发布评审可通过两种形式开展：
- 纳入TC例行会议议程审议
- 由版本发布经理（Release Manager, RM）组织临时专项评审会议
3.2 参会人员要求
- 参会人员需满足社区TC会议决策机制规定的有效人数要求
- 参会角色及职责如下：
- 技术委员会（TC）委员：主导版本发布风险评估，参与最终决策投票
- SIG-Doc代表：审核版本文档的完整性与规范性
- SIG-QA代表：汇报测试执行情况，确认测试结果有效性
- SIG-Security代表：评估版本安全风险，出具安全合规意见
- 社区运作/法务/传播等事务相关人员（可选）：提供发布相关的市场、合规建议
4. 评审会议流程
4.1 会前意见收集
- RM需在会议召开前，向所有参会角色代表分发待发布版本的测试报告、问题清单及版本说明文档
- 各代表需在会前反馈意见，明确版本是否满足评审条件，存在的问题是否影响发布
- RM汇总各方意见，确认版本具备评审条件后，方可推进会议召集
4.2 会议召集
- RM需提前3个工作日发起会议邀约，明确会议时间、参会人员、议程及材料链接
- 确保所有关键角色代表均可参会，无法参会的需委派代理人，并提前告知RM
4.3 会议召开与决策
- 会议由RM主持，议程分为三步：版本情况汇报→代表意见陈述→投票决策
- SIG-QA代表首先汇报测试情况，包括测试覆盖度、问题整改情况及遗留问题说明
- 各参会代表依次发表评审意见，重点说明遗留问题对版本的影响程度
- 针对评审结论进行投票，投票需遵循简单多数原则，且符合TC会议决策机制要求
5. 评审决策规则
| 评审结论 | 判定条件 |
|---|---|
| 同意发布 | 满足以下任一情形即可： 1. 验证测试任务完成，且无待解决问题 2. 验证测试任务完成但存在待解决问题，经参会成员简单多数投票，判定所有问题均不影响版本或组件发布 |
| 延期评审 | 1. 验证测试任务完成但存在待解决问题 2. 经参会成员简单多数投票，判定相关问题影响版本或组件发布 3. 经评估，所有问题均可在拟发布日期前完成整改，拟发布日期由参会成员简单多数投票确定 4. RM需组织问题整改跟进，并在新日期前重新发起评审 |
| 不同意发布 | 1. 验证测试任务完成但存在待解决问题 2. 经参会成员简单多数投票，判定相关问题影响版本或组件发布 3. 经评估，相关问题无法在该版本拟发布日期前全部解决 |
6. 后续动作
- 同意发布：RM协调各团队完成版本打包、发布公告撰写及版本上线工作
- 延期评审：RM建立问题整改台账，跟踪整改进度，确保按时完成并重新发起评审
- 不同意发布：项目团队需针对核心问题进行全面整改，整改完成后重新执行测试流程，再启动新一轮发布评审