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上，也看一下大家的意见。