为什么需要项目版本号？

在实际的需求迭代过程中，我们发现大家在开发需求的过程中，在不同的版本迭代过程中，喜欢用：一期、二期等。

说明

在上图中，多个平台在开发的过程中，不自觉的用上了1期、一期、二期来表示，同一个功能在不停的更新迭代。这种描述，符合人的正常思维。但是，却无法清晰的描述出当前需求迭代的功能变更大小， 是否只是bug的修复，或者是新增了功能，甚至是大的功能演进等。

目前，在软件版本号的控制有各种规范和守则，这里，简单的将平台版本号缩减为三级进行约束版本的更改。

版本号格式

版本格式： ${主版本号}.${次版本号}.${修定号}

• ${主版本号}：当你做了不兼容的API修改，或者大的框架改动。
• ${次版本号}：当你做了向下兼容的功能新增。
• ${修订号}：当你做了向下兼容的问题修正，通常是修复系统的一些重要bug或者漏洞。

遵循规范

平台开发过程中严格遵循上述规范：

• 针对修复问题（只包括：bug或者漏洞），且需要确保不新增功能以及影响代码的稳定性，则递增${修订号}；
• 如果是API保持向下兼容的新增及修改时，则递增${次版本号}；
• 如果是开发了向下不兼容的代码或者改动了已有的代码逻辑，导致已有的代码部分功能不能用，则递增${主版本号}。
• 版本号的权重：${主版本号} > ${次版本号} > ${修订号}，因此，${修订号}的功能修复，也需要体现在${次版本号}和${主版本号}中；同理，${次版本号}的功能新增，也需要体现在${主版本号}中。

版本号内容模板

V1.0.0 范例

项目

• 支持 JDK 16 和 17 @张三
• 添加支持 arm64 的 docker 镜像 @李四

OAP 服务

• 增加 Jackson 的组件定义 @张三
• 修复 zipkin-receiver 插件没有打包进 dist @张三
• 支持 OAL 核心引擎的转换语句 @王五

UI

• 优化端点依赖 @李四
• 添加 ClickHouse logo @张三
• 优化性能分析函数模块 @李四

文档

• 添加文档关于逻辑端点 @张三
• 增强更多关于数据上报和查询的协议的文档 @张三

对外提供服务简化模式

说明：上述三级的版本号，适合于提供API等版本号的控制，但是在统一平台对外提供服务时，可以简化为两级版本号。

版本格式： ${主版本号}.${次版本号}.${修定号} 在对外提供服务时，可简化为：${主版本号}.${次版本号} 即 删除掉 ${修订号}，避免让用户感知到频繁的变更版本。