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. 影响
为什么4.19版本不是共主干开发呢? 搞这么多分支的意义是什么? 请收编分支; 4.19下面应该只能存在2个分支LTS分支和创新版本分支; -----邮件原件----- 发件人: Xie XiuQi [mailto:xiexiuqi@huawei.com] 发送时间: 2020年10月15日 22:18 收件人: Zhanghailiang <zhang.zhanghailiang@huawei.com> 抄送: tc <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.org To unsubscribe send an email to tc-leave@openeuler.org
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 兼容性要求。
-----邮件原件----- 发件人: Xie XiuQi [mailto:xiexiuqi@huawei.com] 发送时间: 2020年10月15日 22:18 收件人: Zhanghailiang <zhang.zhanghailiang@huawei.com> 抄送: tc <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.org To unsubscribe send an email to tc-leave@openeuler.org
为什么 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.com><mailto:zhang.zhanghailiang@huawei.com> 抄送: tc <tc@openeuler.org><mailto: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.org<mailto:tc@openeuler.org> To unsubscribe send an email to tc-leave@openeuler.org<mailto:tc-leave@openeuler.org>
Hi， On 2020/10/17 15:48, Zhoukang (A) wrote:
为什么Branch 22.03 LTS 和 Branch 22.03 LTS SP1 不是共主干开发呢?
是共主干的，只是这个主干是前面图中的 OLK-5.10 长期维护分支。
都是5.10的内核, 你拆分2个分支开发的目的是什么?
openEuler LTS 稳定性优先，发布之后，补丁合入是严格控制的。 用户使用之后，在维护周期内，比如2年内，能获得持续的安全更新 和严重的bugfix，以及一些有明确诉求的、影响范围可控的优化或更新。 SP1 是将1年内的，开源社区更新、优化，以及新开发的内容，汇总发布， 内容相比前面版本的 update 要多，需要的测试周期也长。而且参考业界 做法，比如SuSE、RHEL 等业界主流厂商，其SP版本也是对应不同的分支。 SUSE branches: SLE15-SP1 SLE15-SP2 SLE15-SP3 CentOS/RHEL 的话， 7.1,7.2,7.3 等可以看做不同的SP版本，也是类似。 他做的更好一点，就是版本间维护了一个kabi的白名单。 都是做这个领域的，你肯定也理解。
对内核的诉求是5.10-LTS内核要同时兼容openEuler 22.03 LTS 和openEuler 22.03 LTS SP1 和openEuler 22.03 LTS SP2 等后续演进版本;
我大概明白你的诉求，是不是两个分支不关键，你主要是想4年的生命周期内全都兼容。 兼容性、新特性/优化、维护成本，这三个有显而易见的制约关系，你说的这个方案目前 还做不到。 所以，经过多轮讨论，也参考了业界几个主流OS, 给出了当前的方案。其中 SP 版本维 护较长的时间，就是兼顾了兼容性要求比较强的场景。
已加入议题，谢谢
-----Original Message----- From: Xiexiuqi Sent: Thursday, October 15, 2020 10:18 PM To: Zhanghailiang <zhang.zhanghailiang@huawei.com> Cc: tc <tc@openeuler.org> Subject: 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. 影响
Hi Xiuqi, On 10/15/2020 10:17 PM, Xie XiuQi wrote:
海亮 & 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 的上游版本号是否还是保持与上游一致？ 反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。 版本号是否可以借鉴 一下 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
3. 影响 _______________________________________________ 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.
Hi, 非常感谢参与openEuler kernel 的讨论： On 2020/10/19 13:37, Erik Yuan wrote:
且，如果主干和分支如果在同一个月都发版本时，有可能引起版本号重复。如都是10月份 第2个版本，则版本号后缀都是 -2010.2.0 - <年月>.<月份内Release号> ，不能体现大版本小版本的层级关系
2 改进方案 （以 5.10 内核为例）
版本号格式：(格式与原方案完全相同，只是各字段含义有细微变化）
5.10.0-<开发版本号>.<维护版本号>.<构建号/buildid>
总体思路： - 上游版本号选定后，上游版本号保持不变；只更新下层版本号；
诸如 5.10.0 的上游版本号是否还是保持与上游一致？ 反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。
4.19 上，关于 sublevel 版本号，下游有多次混淆和误解这个含义。而且，就在我准备 回这封邮件的时候，又有人找我澄清这个事情。 比如，以 openEuler 20.03 LTS 为例，对应的内核源码版本号是 4.19.90-2003.4.0， 有多个下游团队误以为这个版本是基于 Linux stable 4.19.90 开发的，在进行上游 社区溯源时就会出错，出现不必要的麻烦。而实际上，针对 Linux stable 的补丁， openEuler kernel 是进行 backport 操作，所以在 git log 中，不能说是基于 4.19.90 开发的，4.19.90-2003.4.0 的上游版本并不是 Linux stable 4.19.90。 （通过 git log 可以发现，openEuler 4.19 kernel 的上游版本是 linux stable 的 4.19.13） c04c050f5bf9 (tag: v4.19.13) Linux 4.19.13 上面提到的“反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。”， 我确实是这个想法：选择了上游社区的某个版本，之后就是在 openEuler 社区的开发、回合， 保持上游版本号固定，之后就只更新openEuler社区的版本号部分。
版本号是否可以借鉴 一下 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。
openEuler LTS 的 kernel 会定期同步 upstream kernel 的，也就是 5.10 也会定期同步 linux stable 5.10.x 的补丁。 确实是这样的，而且 openEuler 的 4.19 内核，再 backport 对应的 stable 版本之后，也会修改 sublevel。 实际执行过程中，遇到上面的问题。也是我提议改成 sublevel version 保持不变的重要原因。当然，在 backport 时， git log 中会描述补丁来自哪个 stable 版本，在 release note 中也会说明，同步到哪个 stable 版本了。 另外，suse 保留了 sublevel 更新的一个原因，应该与其补丁管理方式有关，suse 使用 quilt 管理补丁，相当于 上游 stable 版本有更新时，做了 rebase 操作，更新 sublevel 顺理成章。 关于你上面提到的 dist ver 之类的 string 字段，我的想法是，5.10 的 版本号规则，在 4.19 上微调，尽量 避免在格式上有大的变动，毕竟 4.19 已经有很多下游在使用了;-） 上面是我的观点和理由，再次感谢参与讨论，本周tc上，也看一下大家的意见。
Hi Xiuqi, 多谢详尽的解释, 澄清了好些过往的一些错误理解：） 还有点疑问。 On 10/19/2020 3:22 PM, Xie XiuQi wrote:
Hi,
非常感谢参与openEuler kernel 的讨论：
On 2020/10/19 13:37, Erik Yuan wrote:
且，如果主干和分支如果在同一个月都发版本时，有可能引起版本号重复。如都是10月份 第2个版本，则版本号后缀都是 -2010.2.0 - <年月>.<月份内Release号> ，不能体现大版本小版本的层级关系
2 改进方案 （以 5.10 内核为例）
版本号格式：(格式与原方案完全相同，只是各字段含义有细微变化）
5.10.0-<开发版本号>.<维护版本号>.<构建号/buildid>
总体思路： - 上游版本号选定后，上游版本号保持不变；只更新下层版本号；
诸如 5.10.0 的上游版本号是否还是保持与上游一致？ 反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。
4.19 上，关于 sublevel 版本号，下游有多次混淆和误解这个含义。而且，就在我准备 回这封邮件的时候，又有人找我澄清这个事情。
比如，以 openEuler 20.03 LTS 为例，对应的内核源码版本号是 4.19.90-2003.4.0， 有多个下游团队误以为这个版本是基于 Linux stable 4.19.90 开发的，在进行上游 社区溯源时就会出错，出现不必要的麻烦。而实际上，针对 Linux stable 的补丁， openEuler kernel 是进行 backport 操作，所以在 git log 中，不能说是基于 4.19.90 开发的，4.19.90-2003.4.0 的上游版本并不是 Linux stable 4.19.90。 （通过 git log 可以发现，openEuler 4.19 kernel 的上游版本是 linux stable 的 4.19.13）
c04c050f5bf9 (tag: v4.19.13) Linux 4.19.13
也就是目前从stable同步 4.19.x 后 修改openEuler kernel的sublevel 是与 stable 的x不一致的？ 目前是 openEuler 的sublevel > 主线的sublevel。 之前理解openEuler kernel的sublevel 是对应stable kernel的sublevel。 那么如果基于新方案，引入 <开发版本>.<维护版本>后，是否可以将sublevel 在某个tag后调整回去与 stable保持一致？ 然后sublevel 只在每次与stable kernel同步后 才更新演进。期间发生的kernel build版本只是变更 <开发版本>?? 这样从openEuler kernel的版本号能比较直观的建立与stable kernel的关系。
上面提到的“反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。”， 我确实是这个想法：选择了上游社区的某个版本，之后就是在 openEuler 社区的开发、回合， 保持上游版本号固定，之后就只更新openEuler社区的版本号部分。
版本号是否可以借鉴 一下 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。
openEuler LTS 的 kernel 会定期同步 upstream kernel 的，也就是 5.10 也会定期同步 linux stable 5.10.x 的补丁。 确实是这样的，而且 openEuler 的 4.19 内核，再 backport 对应的 stable 版本之后，也会修改 sublevel。 实际执行过程中，遇到上面的问题。也是我提议改成 sublevel version 保持不变的重要原因。当然，在 backport 时， git log 中会描述补丁来自哪个 stable 版本，在 release note 中也会说明，同步到哪个 stable 版本了。
另外，suse 保留了 sublevel 更新的一个原因，应该与其补丁管理方式有关，suse 使用 quilt 管理补丁，相当于 上游 stable 版本有更新时，做了 rebase 操作，更新 sublevel 顺理成章。
关于你上面提到的 dist ver 之类的 string 字段，我的想法是，5.10 的 版本号规则，在 4.19 上微调，尽量 避免在格式上有大的变动，毕竟 4.19 已经有很多下游在使用了;-）
目前 openEuler的kernel版本号 能区分innovation 和 LTS 么？ 按照目前 LTS 和 innovation 选择 upgrade kernel的策略（都选择Linux LTS)， 可以出现 openEuler 某个LTS 版本选择的 Linux kernel LTS版本 与innovation版本选择的 Linux kernel LTS版本一致的情况。 此时如何区分两个版本所发布的kernel包？ <开发版本> 我理解应该是从属于 VERSION.PATCHLEVEL.SUBLEVEL 下的，而不是整个openEuler 全局编号的。 谢谢！ Erik
上面是我的观点和理由，再次感谢参与讨论，本周tc上，也看一下大家的意见。
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.
Hi, 尝试按我的理解解释了一下；-） On 2020/10/20 13:39, Erik Yuan wrote:
Hi Xiuqi,
多谢详尽的解释, 澄清了好些过往的一些错误理解：） 还有点疑问。
On 10/19/2020 3:22 PM, Xie XiuQi wrote:
Hi,
非常感谢参与openEuler kernel 的讨论：
On 2020/10/19 13:37, Erik Yuan wrote:
且，如果主干和分支如果在同一个月都发版本时，有可能引起版本号重复。如都是10月份 第2个版本，则版本号后缀都是 -2010.2.0 - <年月>.<月份内Release号> ，不能体现大版本小版本的层级关系
2 改进方案 （以 5.10 内核为例）
版本号格式：(格式与原方案完全相同，只是各字段含义有细微变化）
5.10.0-<开发版本号>.<维护版本号>.<构建号/buildid>
总体思路： - 上游版本号选定后，上游版本号保持不变；只更新下层版本号；
诸如 5.10.0 的上游版本号是否还是保持与上游一致？ 反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。
4.19 上，关于 sublevel 版本号，下游有多次混淆和误解这个含义。而且，就在我准备 回这封邮件的时候，又有人找我澄清这个事情。
比如，以 openEuler 20.03 LTS 为例，对应的内核源码版本号是 4.19.90-2003.4.0， 有多个下游团队误以为这个版本是基于 Linux stable 4.19.90 开发的，在进行上游 社区溯源时就会出错，出现不必要的麻烦。而实际上，针对 Linux stable 的补丁， openEuler kernel 是进行 backport 操作，所以在 git log 中，不能说是基于 4.19.90 开发的，4.19.90-2003.4.0 的上游版本并不是 Linux stable 4.19.90。 （通过 git log 可以发现，openEuler 4.19 kernel 的上游版本是 linux stable 的 4.19.13）
c04c050f5bf9 (tag: v4.19.13) Linux 4.19.13
也就是目前从stable同步 4.19.x 后 修改openEuler kernel的sublevel 是与 stable 的x不一致的？ 目前是 openEuler 的sublevel > 主线的sublevel。 之前理解openEuler kernel的sublevel 是对应stable kernel的sublevel。
是一致的。openEuler kernel 回合 4.19.x 的补丁之后，sublevel 就变为 x. 在 4.19 上，实际上是把 stable 中修改 Makefile sublevel 的补丁也backport回来了。 commit 94a531f89cf3c6c40bebee7acab581a8033a5283 (HEAD -> kernel-4.19, origin/kernel-4.19) Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Date: Mon Oct 19 21:23:04 2020 +0800 Linux 4.19.152 Merge 19 patches from 4.19.152 stable branch (22 total) beside 3 already merged patches: 128278f444ab Bluetooth: A2MP: Fix not initializing all members 360f80e34292 Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel 7b2e80606a5d Bluetooth: MGMT: Fix not checking if BT_HS is enabled Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Link: https://lore.kernel.org/r/20201016090437.301376476@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> diff --git a/Makefile b/Makefile index f2c9db9b4015..aa79ce7bfdc7 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 4 PATCHLEVEL = 19 -SUBLEVEL = 151 +SUBLEVEL = 152 EXTRAVERSION = NAME = "People's Front"
那么如果基于新方案，引入 <开发版本>.<维护版本>后，是否可以将sublevel 在某个tag后调整回去与 stable保持一致？ 然后sublevel 只在每次与stable kernel同步后 才更新演进。期间发生的kernel build版本只是变更 <开发版本>?? 这样从openEuler kernel的版本号能比较直观的建立与stable kernel的关系。
我原本也是你说的这个思路，而且 4.19 也是这么做的，完整的合入社区 stable 的版本 4.19.x 之后，sublevel 也改为 x。 是由于前面我提到的一些误解，所以现在想保持 sublevel 不变。 不过，我个人是可以接受 seblevel 与回合的社区 4.19.x 的相同的。 虽然从严格意义上讲，由于已经合入了其他的补丁，openEuler kernel sublevel 的含义与 stable 的有细微的差别， 但确实是能与 stable kernel 建立直观的联系。 有利有弊，对熟悉 kernel 开发的人来说，与 stable kernel 的sublevel建立联系，能帮助我们了解跟踪到了哪个 stable 版本。 对于不熟悉 kernel 开发的人来说，他看到就是一个版本号，他们以为 sublevel 变了，就后面的一切都变了。或者以为你这个 版本的 base 就是 VERSION.PATCHLEVEL.SUBLEVEL。
上面提到的“反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。”， 我确实是这个想法：选择了上游社区的某个版本，之后就是在 openEuler 社区的开发、回合， 保持上游版本号固定，之后就只更新openEuler社区的版本号部分。
版本号是否可以借鉴 一下 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。
openEuler LTS 的 kernel 会定期同步 upstream kernel 的，也就是 5.10 也会定期同步 linux stable 5.10.x 的补丁。 确实是这样的，而且 openEuler 的 4.19 内核，再 backport 对应的 stable 版本之后，也会修改 sublevel。 实际执行过程中，遇到上面的问题。也是我提议改成 sublevel version 保持不变的重要原因。当然，在 backport 时， git log 中会描述补丁来自哪个 stable 版本，在 release note 中也会说明，同步到哪个 stable 版本了。
另外，suse 保留了 sublevel 更新的一个原因，应该与其补丁管理方式有关，suse 使用 quilt 管理补丁，相当于 上游 stable 版本有更新时，做了 rebase 操作，更新 sublevel 顺理成章。
关于你上面提到的 dist ver 之类的 string 字段，我的想法是，5.10 的 版本号规则，在 4.19 上微调，尽量 避免在格式上有大的变动，毕竟 4.19 已经有很多下游在使用了;-）
目前 openEuler的kernel版本号 能区分innovation 和 LTS 么？
openEuler kernel source 的版本号，没有区分 innovation 和 LTS。 我理解应该是看 openEuler 版本的发布时机，来选择采用哪个版本的 openEuler kernel。 按照现在的 LTS 策略，肯定会出现 innovation 和 LTS 都采用 5.10 内核的情况， 但是由于 innovation 和 LTS 发布时机不同，选用内核时，<开发版本> 是不同的。 更极端的情况，innovation 和 LTS 假设选择的内核，<开发版本> 也相同，那也好办， innovation 和 LTS 这时就干脆使用相同版本的内核，包括 Maintenance 号。可能只是 打包时，rpm 包的后缀有区别，oe1 这个字段。
按照目前 LTS 和 innovation 选择 upgrade kernel的策略（都选择Linux LTS)， 可以出现 openEuler 某个LTS 版本选择的 Linux kernel LTS版本 与innovation版本选择的 Linux kernel LTS版本一致的情况。 此时如何区分两个版本所发布的kernel包？ <开发版本> 我理解应该是从属于 VERSION.PATCHLEVEL.SUBLEVEL 下的，而不是整个openEuler 全局编号的。
<开发版本> 是 openEuler kernel 全局的，是在 4.19、5.10 等，每个大版本范围内是全局的， 不是从属 VERSION.PATCHLEVEL.SUBLEVEL， 而是可以理解为从属 VERSION.PATCHLEVEL。 不管 SUBLEVEL 更新还是保持不变，都不应该影响 <开发版本> 的更新。 如果 <开发版本> 从属于 VERSION.PATCHLEVEL.SUBLEVEL 的话，会有问题，就会出现 下面这样的版本号序列，体现不出openEuler kernel 的演进关系，<开发版本> 会经常 reset. 三个思路对比： <从属 sublevel> <sublevel更新,开发版本全局> <sublevel 不更新> 5.10.1-1.0.0 5.10.1-1.0.0 5.10.0-1.0.0 5.10.1-2.0.0 5.10.1-2.0.0 5.10.0-2.0.0 5.10.1-3.0.0 5.10.1-3.0.0 5.10.0-3.0.0 5.10.1-4.0.0 5.10.1-4.0.0 5.10.0-4.0.0 5.10.2-1.0.0 5.10.2-4.0.0 5.10.0-5.0.0 5.10.3-1.0.0 5.10.3-4.0.0 5.10.0-6.0.0 5.10.3-2.0.0 5.10.3-5.0.0 5.10.0-7.0.0 综上，应该是上面 2 3 两个方案里面选择一个，我之前说的是方案3，如果更新 sublevel 的话， 就是方案2。我个人倾向于3，但我能接受2.
谢谢！ Erik
上面是我的观点和理由，再次感谢参与讨论，本周tc上，也看一下大家的意见。
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.
participants (4)
-
Erik Yuan -
Xie XiuQi -
Zhanghailiang -
Zhoukang (A)