为什么 Branch 22.03 LTS 和 Branch 22.03 LTS SP1 不是共主干开发呢? 都是5.10的内核, 你拆分2个分支开发的目的是什么?
对内核的诉求是 5.10-LTS内核要同时兼容 openEuler 22.03 LTS 和 openEuler 22.03 LTS SP1 和 openEuler 22.03 LTS SP2 等后续演进版本;
发件人: Xiexiuqi 发送时间: 2020年10月17日 14:55 收件人: Zhoukang (A) zhoukang7@huawei.com; Zhanghailiang zhang.zhanghailiang@huawei.com 抄送: tc tc@openeuler.org 主题: Re: 答复: [Tc] TC 议题申报：openEuler kernel 5.10 内核版本号规则改进方案
On 2020/10/16 16:29, Zhoukang (A) wrote:
为什么4.19版本不是共主干开发呢?
搞这么多分支的意义是什么?
请收编分支; 4.19下面应该只能存在2个分支LTS分支和创新版本分支;
我理解你想要的可能是 kernel-4.19 这个分支，这个是持续向前演进的。 其他的分支是配合 openEuler 的发行版本出的维护分支，不同的发行版 版本定位有区别，版本时间点和周期也有不同，所以会存在多个分支。
以接下来的 5.10 为例的话，kernel 分支的思路，可以看一下。 和 4.19 类似，也是会有一个长期的维护分支，一直在演进，但是 kabi 不保持。 其他的分支是配合不同时期的 openEuler 发行版的维护分支，其中 openEuler LTS 发行版有一定的 kabi 兼容性要求。
[cid:image001.png@01D6A49C.FE123D70]
-----邮件原件-----
发件人: Xie XiuQi [mailto:xiexiuqi@huawei.com]
发送时间: 2020年10月15日 22:18
收件人: Zhanghailiang zhang.zhanghailiang@huawei.commailto:zhang.zhanghailiang@huawei.com
抄送: tc tc@openeuler.orgmailto:tc@openeuler.org
主题: [Tc] TC 议题申报：openEuler kernel 5.10 内核版本号规则改进方案
海亮 & TC，
议题申报：openEuler kernel 5.10 内核版本号改进方案
（总体方案和 RHEL/CentOS kernel 版本号规则类似）
1. 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 是开发分支的上游，选定后，保持不变；开发分支有更新，只升级<开发版本号>
- 开发分支是维护分支的上游，一旦选定某个开发版本，转维护时，只升级<维护版本号>
- 通过<开发版本号>和<维护版本号>，体现开发与维护的关系
- 主干开发与多个维护分支共同存在时，版本号不混淆，能清晰体现上下游关系
各字段具体说明：
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
3. 影响
_______________________________________________
Tc mailing list -- tc@openeuler.orgmailto:tc@openeuler.org
To unsubscribe send an email to tc-leave@openeuler.orgmailto:tc-leave@openeuler.org
