Hi Xiuqi,
On 10/15/2020 10:17 PM, Xie XiuQi wrote:
海亮 & TC，
议题申报：openEuler kernel 5.10 内核版本号改进方案 （总体方案和 RHEL/CentOS kernel 版本号规则类似）
- openEuler kernel 版本号，原方案及存在的问题 （以 4.19 为例）
版本号格式：
4.19.<stable 版本号>-<年月>.<月份内Release号>.<buildid>
说明：
- <stable 版本号>，linux stable 分支版本，合入对应的stable 版本时更新 如 4.19.90， 4.19.128 等等
- <年月>，标识版本发布时的年份&月份，如 2010 表示2020年10月份，2009 表示20年9月份
- <月份内Release号>，标识本月内发布的第几个版本，比如 2020年10月份发的第2个版本，则 版本号为 xxxx-2020.2.0
- buildid, 构建号，不管是代码还是制品仓，只要有修改要出rpm包，就在之前基础上 +1
存在的问题：
- 上述方案，如果只有一条分支，则问题不大，版本号顺序增加
- 如果有多个分支，则可能存在分之间版本号混淆，不能体现主干与分支的关系等问题
- 比如，主干在开发时，<stable 版本号>.<年月>.<月份内Release号> 这几个版本号都 在变化；openEuler发布后，<年月>.<月份内Release号> 这几个版本号也都在更新， 且，如果主干和分支如果在同一个月都发版本时，有可能引起版本号重复。如都是10月份 第2个版本，则版本号后缀都是 -2010.2.0
- <年月>.<月份内Release号> ，不能体现大版本小版本的层级关系
2 改进方案 （以 5.10 内核为例）
版本号格式：(格式与原方案完全相同，只是各字段含义有细微变化）
5.10.0-<开发版本号>.<维护版本号>.<构建号/buildid>
总体思路：
- 上游版本号选定后，上游版本号保持不变；只更新下层版本号；
诸如 5.10.0 的上游版本号是否还是保持与上游一致？ 反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。
版本号是否可以借鉴 一下 suse的，例如 5.3.18-18.21--sle15-sp2
5.3.18-lp152.19.2
之类，通过添加一个dist ver之类的string字段来区分。 是否能解决问题？ 个人觉得openEuler LTS的kernel 还是会不时同步对应的 upstream kernel的，也就是 5.10.x而不是 sublevel 总是0。
cheers, Erik
- 社区 5.10.0 是开发分支的上游，选定后，保持不变；开发分支有更新，只升级<开发版本号>
- 开发分支是维护分支的上游，一旦选定某个开发版本，转维护时，只升级<维护版本号>
- 通过<开发版本号>和<维护版本号>，体现开发与维护的关系
- 主干开发与多个维护分支共同存在时，版本号不混淆，能清晰体现上下游关系
各字段具体说明： 1） 5.10.0 前面的基础版本号不变，一直是 5.10.0，不体现 stable 的小版本号； 2） 后面几位是 <开发版本号>-<维护版本号>-<构建号/buildid> 比如：5.10.0-2.0.0.0007.oe1.aarch64 %global upstream_version 5.10 %global upstream_sublevel 0 %global devel_release 2 %global maintenance_release .0.0 %global buildid .0007
3）版本号思路： - 开发的时候，只更新<开发版本号>，<维护版本号>保持为 .0.0 - openEuler 发行版发布之后，只更新<维护版本号>，<开发版本号>固定不变 - <构建号/buildid>，构建号，不管是代码还是制品仓，只要有修改要出rpm包，就在之前基础上 +1
4）例子：
开发的时候，只更新<开发版本号>，维护版本号保持为 .0.0 源码 tag: 5.10.0-1.0.0， 制品仓 release: 5.10.0-1.0.0.0001.oe1.aarch64 源码 tag: 5.10.0-2.0.0， 制品仓 release: 5.10.0-2.0.0.0002.oe1.aarch64 源码 tag: 5.10.0-3.0.0， 制品仓 release: 5.10.0-3.0.0.0003.oe1.aarch64
openEuler 发行版发布之后，假设从 5.10.0-123.0.0 开发版本转 openEuler 发布， 之后再合入维护补丁，就只更新维护版本号 （最后那个 0 预留，紧急情况下使用）
源码 tag: 5.10.0-123.1.0 制品仓 release: 5.10.0-123.1.0.0041.oe1.aarch64 源码 tag: 5.10.0-123.2.0 制品仓 release: 5.10.0-123.2.0.0042.oe1.aarch64 源码 tag: 5.10.0-123.3.0 制品仓 release: 5.10.0-123.3.0.0043.oe1.aarch64 。。。
假设后续有 SP 版本从 5.10.0-456.0.0 开发版本发布，之后再合入维护补丁，就只更新<维护版本号>
源码 tag: 5.10.0-456.1.0 源码 tag: 5.10.0-456.2.0 源码 tag: 5.10.0-456.3.0 。。。
开发分支上回合 stable 补丁时，也是只更新<开发版本号>
5）相比之前的好处： 相比之前通过月份来定版本号的好处，通过区分开发版本号，和维护版本号，体现主干 和和维护分支的关系。
之前月份命名版本号，在分支多的情况下，存在混淆的情况，比如，相同月份不同分支 的 release 号可能会重复，比如都是10月份的第一个版本：-2010.1.0
- 影响
Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.