mirror of
https://gitee.com/openharmony/release-management
synced 2024-11-23 06:30:01 +00:00
3c230e279c
Signed-off-by: lnlan <lanleinan4@huawei.com>
5.3 KiB
5.3 KiB
本规范定义的“版本发布”是经OpenAtom OpenHarmony(以下简称“OpenHarmony”)的项目管理委员会(以下简称“PMC”)认可并正式发布的版本。
版本发布要求
- 测试要求:待发布版本需经过测试SIG测试,并获得测试通过的报告。
- 法务合规要求:待发布版本需遵从《OpenHarmony项目许可证指导》(待发布)、《许可证与版权规范》与《第三方开源软件引入指导》,并满足合规SIG发布的所有合规要求。
- 质量要求:待发布版本需满足QA SIG发布的《版本质量要求》
版本发布评审
PMC授权Release SIG组织版本发布评审。每个OpenHarmony社区版本(Beta/Release/LTS)均应通过版本发布评审。
评审前
- 评审会前意见收集:OpenHarmony社区在版本(Beta/Release/LTS需组织评审)评审之前,收集测试SIG、QA SIG、合规SIG、法务和合规组代表等意见,以此确定本版本是否满足版本发布评审的条件。
- 评审会议发起及召集:版本发布原则上采用会议的形式进行,并由Release SIG代表提前三天发布评审会议电子邮件通知 。
- 版本发布评审组的核心成员:PMC成员、资料SIG代表、合规SIG代表、法务与合规组代表及基金会法务代表。评审会议电子邮件通知所有主送成员均应参加,其中PMC成员应有二分之一及以上成员参加,测试SIG、QA SIG必须参加。前述代表名单应在评审会议开始前确定。
- 评审会议电子邮件通知主送:版本发布评审组的核心成员,抄送:dev@openharmony.io。
评审过程及结论
版本发布评审由Release SIG代表主持,评审组根据测试报告、质量要求检查报告(含遗留问题及合规清零报告等),每个代表发布评审意见,共同评审是否同意版本发布。
在版本正式发布之前已经执行了与发布阶段相对应的所有验证测试活动,并且不存在待解决的影响版本或组件发布的问题,是评审组同意发布该版本的前提。
评审结论:同意发布/延期评审/不同意发布。
-
“同意发布”:满足以下情形之一即为“同意发布”(1)验证测试任务完成,且不存在待解决的问题;(2)验证测试任务完成但存在待解决的问题,经参会PMC成员通过简单多数投票决定存在的问题均不影响版本或组件的发布。
-
“延期评审”:验证测试任务完成但存在待解决的问题,经参会PMC成员通过简单多数投票决定相关问题影响版本或组件的发布,且预期相关问题均可在该版本的拟发布日期(可由参会PMC成员满足简单多数投票决定具体日期)之前解决,则应延期重新发起评审。
-
“不同意发布”:验证测试任务完成但存在待解决的问题,经参会PMC成员通过简单多数投票决定相关问题影响版本或组件的发布,且预期相关问题无法在该版本的拟发布日期之前全部解决,则评审结论为“不同意发布”。
评审结论说明
- 一旦版本被评审为“同意发布”,其状态就无法更改。
- 一旦版本被评审为“不同意发布”,则取消本次版本发布。
版本发布及责任组织
序号 | 内容描述 | 活动要求说明 | 责任组织 |
---|---|---|---|
1 | 评审纪要归档至社区 | 评审纪要发布,主送:评审组成员,抄送:dev@openharmony.io | SIG-Release |
2 | 合规扫描清零报告 | 合规告警清零并向基金会秘书处提供拟发布版本的清零报告 | SIG-Release |
3 | 社区版本版本包发布 | 社区版本分支TAG归档,版本获取链接更新并验证(含SDK) | SIG-Release |
4 | 社区版本发布后用户验证 | 针对最终发布版本的验证,确保与计划发布版本一致,含两种方式: 1. Repo拉取源码获取、编译烧录、亮屏 2. Docker环境下的编译、烧录、亮屏 |
SIG-测试 |
5 | 测试报告、Release notes发布社区 | 测试报告、Release notes发布社区 | SIG-资料、SIG-测试 |
6 | 版本发布社区邮件推送 | 版本发布社区邮件推送 | SIG-Release |
7 | 版本发布社区公告 | 在OpenHarmony主页发布公告 | SIG-Release |
生效及修订
本规范及其任何修订应经PMC批准后生效。
规范版本修订记录
V2.0 2022年10月25日更新