TPC-SIG项目版本发布规范
OpenHarmony-TPC 版本发布指导
发布准则
发布的三方库必须遵循以下规则
-
发布的三方库必须有明确的功能。
-
发布的三方库库命名需规范。请参考OpenHarmony 三方库名称指南。
-
发布的三方库需包含Readme文件。
建议ReadMe中包含简介,下载安装,所需权限,使用示例,接口说明,约束与限制
(支持API几,SDK版本),目录结构,贡献代码,开源协议。
-
发布的三方库必须包含License 文件。
-
发布的三方库需包含ChangeLog文件。
-
发布的三方库版本命名需规范。 请参照版本号命名规则。
-
发布的三方库版本需要遵循开源三方库版本质量要求。
OpenHarmony-TPC 版本发布评审
PMC授权TPC SIG组织版本发布评审。每个三方库版本(Release/RC)均应通过版本发布评审。
评审前
-
评审会前意见收集:
TPC SIG在版本(Release/RC需组织评审)评审之前,收集测试、QA、合规、法务代表等意见,以此确定本版本是否满足版本发布评审的条件。
-
评审会议发起及召集:
版本发布原则上采用会议的形式进行,并由TPC SIG代表提前三天发布评审会议电子邮件通知。
-
版本发布评审组的核心成员:
TPC leader成员、合规代表、法务与合规组代表及基金会法务代表。评审会议电子邮件通知所有主送成员均应参加,其中TPC leader成员应有二分之一及以上成员参加,测试、QA 必须参加。前述代表名单应在评审会议开始前确定。
-
评审会议电子邮件通知主送:
版本发布评审组的核心成员,抄送:dev@openharmony.io。
评审过程及结论
- 版本发布评审由版本发布经理代表主持,每月一次,紧急发布可临时召集。范围包含Flutter、RN框架以及依赖的生态三方库;开源通用三方库,含OpenHarmongy-TPC和OpenHarmongy-SIG下的北向应用开源三方库。
- 评审组根据测试报告、质量要求检查报告(含遗留问题及合规清零报告等),每个代表发布评审意见,共同评审是否同意版本发布。
- 在版本正式发布之前已经执行了与发布阶段相对应的所有验证测试活动,并且不存在待解决的影响版本或组件发布的问题,是评审组同意发布该版本的前提。
- 评审结论:同意发布/延期评审/不同意发布。
“同意发布”:满足以下情形之一即为“同意发布”(1)验证测试任务完成,且不存在待解决的问题;(2)验证测试任务完成但存在待解决的问题,经参会TPC SIG成员通过简单多数投票决定存在的问题均不影响版本或组件的发布。
“延期评审”:验证测试任务完成但存在待解决的问题,经参会TPC SIG成员通过简单多数投票决定相关问题影响版本或组件的发布,且预期相关问题均可在该版本的拟发布日期(可由参会TPC SIG成员满足简单多数投票决定具体日期)之前解决,则应延期重新发起评审。
“不同意发布”:验证测试任务完成但存在待解决的问题,经参会TPC SIG成员通过简单多数投票决定相关问题影响版本或组件的发布,且预期相关问题无法在该版本的拟发布日期之前全部解决,则评审结论为“不同意发布”。
评审结论说明
- 一旦版本被评审为“同意发布”,其状态就无法更改。
- 一旦版本被评审为“不同意发布”,则取消本次版本发布。
版本发布及责任组织
| 序号 | 内容描述 | 活动要求说明 | 责任组织 |
|---|---|---|---|
| 1 | 评审纪要归档至社区 | 评审纪要发布,主送:评审组成员,抄送:dev@openharmony.io | TPC SIG |
| 2 | 合规扫描清零报告 | 合规告警清零并向基金会秘书处提供拟发布版本的清零报告 | TPC SIG |
| 3 | 社区版本版本包发布 | 社区版本分支TAG归档,版本获取链接更新并验证 | TPC SIG |
| 4 | 社区版本发布后用户验证 | 针对最终发布版本的验证,确保与计划发布版本一致,含两种方式: 2. ohpm拉取二进制包进行测试验证 |
测试 |
| 5 | 测试报告、Release notes发布社区 | 测试报告、Release notes发布社区 | 测试 |
| 6 | 版本发布社区邮件推送 | 版本发布社区邮件推送 | TPC SIG |
| 7 | 版本发布社区公告 | 在OpenHarmony-TPC主页发布公告 | TPC SIG |