Spring Boot 又升级了！版本该如何选择？
导读：本文基于官方的版本结合自己的产品以及项目版本管理，来分析软件版本的定义相关问题，总结本篇文章希望对从事相关工作的同学能够有所帮助或者启发。
背景
由于前几天定位一个问题的时候发现Spring Boot 在v2.7.0版本之后才修复的问题
出于好奇追溯了在这个问题在分支上管理的过程，加上查阅一些资料。发现官方对于的版本的管理非常值得学习和借鉴。
打开Spring Boot 官网查看版本列表如下：
Spring Boot : https://spring.io/projects/spring-boot#learn
这些数字和单词是什么意思？解释一下
我的理解是：由两个部分组成，一个是用来标识版本的版本号，另外一个是该版本当前的发布状态。如
版本号
Spring Boot 的版本号由 3 位组成，这里还是以上边两个版本为例，如下图：
- 主版本：有可能进行大的架构调整，各大版本之间并不一定兼容
- 次版本：在主版本架构不变的前提下，增加了一些新的特性或变化
- 增量版本：bug 修复，细节的完善，用来描增量版本的，不一定是数字，例如：3.0.0-SNAPSHOT
发布状态
发布状态也有很多同行人称为发布计划，常见的有以下几个：
- GA：General Availability，正式发布的版本，官方推荐使用该版本，国外很多项目都是使用GA来表示正式发布版本的
- PRE：预览版，主要是用来内部开发人员和测试人员测试使用，因此不建议使用
- SNAPSHOT：快照版，可以稳定使用，且该版本会一直进行小量的优化和改进
- RC：Release，该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
▐ 稳定性
PRE < SNAPSHOT < RC <GA
因此我们在使用SpringBoot为基座构建自己的应用时候，通常会优先选择GA版本，因为它的稳定性最高！
如上篇文章中提到JobExecutionExitCodeGenerator 线程安全问题。快手的大佬是在 v 2.5.x 版本发现问题，官方在 v 2.6.x 中的小版本修复。并合并到 v 2.7.0-releases tag 中。最后 v3.0.0-M3 Pre-release 发布稳定版本。
版本拓展
基于SpringBoot 的官方版本，我们公司在产品升级上也会做相应的版本管理。
▐ 分支管理
标准产品稳定后合并至master分支，基于主干线develop 分支拉取迭代分支功能开发分支或者缺陷修复分支 feature-xxx . 如:
- 修复缺陷 feature/fix-0527 (修复缺陷单号为0527的缺陷)
- 迭代功能任务 feature-1024 (开发需求单号为1024的功能)
对应功能或者缺陷处理完后可合并至冒烟分支smoke 进入冒烟环境测试验收，功能没有问题则合并至 develop 开发标准分支
在主功能完善后统一调整版本序号和发版标识。也就是我们常说的打标签tag
对于文档版本分支我们会定义两种版本
- N 版 ：一周或者两周迭代产生的版本(包含修复缺陷)
- R 版 ： 完整迭代功能闭环(包含大部分已修复)
上线版本我们一般采用R 版本应对，对于N版我们会对接各部分的迭代计划以及压测环境
总结
软件版本的定义，由于部门的匹配各公司都有各公司的管理方式和手段。基于Spring Boot 官方的版本定义，可以看出Spring Boot 对于以开源的版本维护以及迭代非常严谨，包括一些问题的产生以及整个回溯过程在GitHub上也是相当有章法。总结本篇文章希望对从事相关工作的同学能够有所帮助或者启发。
软件后续计划针对软件版本管理详细整理几篇文章，以及个分支如何管控和迭代计划的周期的闭环，欢迎关注订阅~