前言
来啦老铁！
一晃半个月过去了，7月也已成为过去，8月学习正当时！
今天咱们来学点“软技能”，也就是不打算写代码了~
背景
笔者到这家公司后，根据当时的版本管理方式，把这种方式做成自动的了，用起来还是蛮香的，但随着项目的推进和版本的交付，一些问题也暴露出来了：
- 这种版本管理仅仅是一种简单的版本号递增，“管理”无从谈起；
- 新发布的版本我们不知道是做了什么类型的改动、是不是向下兼容的、客户端是不是可以升级等问题；
于是越发需要一种版本管理来解决这类问题！
语义化版本管理
从公司其他团队了解到一种版本管理方式：“语义化版本管理”，咱们一起来学习学习~
咱们从以下几个方面来学习一下：
- 语义化版本管理的优点；
- 语义化版本管理的缺点；
- 语义化版本管理简介；
- 语义化版本管理指导；
- 版本号辅助确定工具；
参考文献：
1. 语义化版本管理的优点
-
版本号及其更新方式包含了相邻版本间的底层代码和修改内容的信息；
-
由于版本号本身具有说明本次改动的类型（是否向下兼容等），因此能更好的解答使用方的问题：新版本出来了，我到底能不能升级；
2. 语义化版本管理的缺点；
- 语义化版本号的「语义化」是针对机器而不是人类而言的，我们只能从版本号变更中获取少量的信息；
- 有时候难以判断一个版本对另一个版本的「兼容性」到底如何，有时候一个改动既可以说是一个补丁号更新，也可以说是一个小版本甚至大版本更新；
- 版本号应该面向需求而非面向实现；
- 版本号应包含更多信息和语义化版本号不足以描述复杂的兼容性；
虽然语义化版本控制存在一些缺点，但不失为一种更好的版本控制方法；
3. 语义化版本管理简介；
版本格式：主版本号.次版本号.修订号(MAJOR.MINOR.PATCH)，版本号递增规则如下：
- 主版本号(MAJOR)：当你做了不兼容的接口修改；
- 次版本号(MINOR)：当你做了向下兼容的功能性新增；
- 修订号(PATCH)：当你做了向下兼容的问题修正。
先行版本号及版本编译元数据可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
备注：三个版本号均为十进制数字，且无大小上限，例如 42.1.23 也是一个正常的版本号；
4. 语义化版本管理指导；
- 对外发布的版本均为3位数版本号；
- 内部测试的版本，有多种延伸方式，我们定好选用一种，如 alpha 或 beta，我们可以定beta，则使用版本号如：2.1.5-beta、2.1.5-beta.1、2.1.5-beta.2；
- 2.1.5-beta、2.1.5-beta.1、2.1.5-beta.2 这些内部测试版本对应的外部发布版本为：2.1.5；
- 版本号递增规则参照上述的 ”语义化版本控制介绍“；
5. 版本号辅助确定工具；
综上，我们会发现，决定版本号是由代码改动类型、打包类型决定的，而这些是主观方面的，也即版本号的决定是主观决定的，再也不能简单自动递增了！
为了帮助开发、测试人员更快的决定打包版本号，我们可以考虑制作一款版本号辅助确定工具，如此，打包流程大致为（图片太长了哈，见谅）：
打包流程1
打包流程2
版本号辅助确定工具我也开发了个大概：
版本号辅助确定工具 1
版本号辅助确定工具 2
版本号辅助确定工具 3
版本号辅助确定工具 4
版本号辅助确定工具 5
打包人员只需要按工具上的提示，选择好发布对象、发布类型、改动类型，即可点击“生成版本号”按钮帮我们生成版本号，点击“前往打包按钮”可以跳转到打包平台，我们使用的是 Jenkins，Jenkins 安装好 “Build With Parameters” 插件，可以在Jenkins url上带上打包参数值，则打开 Jenkins job 后就会帮我们自动填充好打包参数啦，也是相当方便的。
Build With Parameters 插件参考文献：https://plugins.jenkins.io/build-with-parameters/#documentation
最后我打算再加一个版本纪要浏览页面，完美~
（工具的代码未公开哈，相对简单，有需要可以跟我交流一下哈）
OK，今天就到这吧，愿每天都有好事发生，愿明天有好事发生~
如果本文对您有帮助，麻烦动动手指点点赞？
谢谢！
网友评论