为什么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