版本号命名规范,为软件开发注入秩序

2024-09-11 158 0

1.版本管理痛点

最近团队在多项目多版本迭代过程中因一直没有版规范化,导致很多存在的问题,总结如下:

  • 版本管理混乱,不知道版本什么时候打的,不同项目迭代功能版本交织在一起无法区分,会出现经常发错版,版本号命名五花八门。

  • 自动化构建和部署问题:自动化系统通常依赖于版本号来确定构建和部署流程,不规范的版本号可能导致自动化系统出错。

  • 版本回溯问题:不规范的版本会导致历史项目很难找到正确的文档和源代码

  • 维护困难:当需要维护和更新软件时,不规范的版本号会增加识别和定位特定版本所需要付出的努力

  • 优先级混乱:在多个版本并行开发时,不规范的版本号可能导致无法确定哪个版本是最稳定或最优先的版本

  • 沟通障碍:团队成员没有达成一致的迭代版本规范,导致沟通不畅和期望不一致。

2.版本规范定义

软件版本号命名规范开发过程中的一个重要组成部分,版本号由四个部分组成,格式为:主版本号.次版本号.修订版本号.日期版本号

file

  • 主版本号
    定义:主版本号用于表示软件架构或功能的重大变更。当软件进行了全面的重构或引入了不兼容的重大变更时,主版本号增加。
    修改规则:当功能模块有较大的变动,比如增加模块或是整体架构发生变化时,主版本号增加。

  • 次版本号
    定义:次版本号用于表示新增了重要的功能或进行了重要的改进,但保持向下兼容。
    修改规则:当增加新的业务功能,并且向下兼容时,次版本号增加。

  • 修订版本号
    定义:修订版本号用于表示进行了小的修正或改进,如修复bug或进行小的功能调整。
    修改规则:一般是Bug的修复或是一些小的变动或是一些功能的扩充,要经常发布修订版,修复一个严重Bug即可发布一个修订版。

  • 日期版本号
    定义:日期版本号用于记录软件更新的具体日期。
    修改规则:每天对项目的修改都需要更改日期版本号。

3.版本正例

  • v1.1.0.240910_1    v1.1.0在2024年09月10号第一次提测版本
  • v1.1.0.240910_2    v1.1.0在2024年09月10号第二次提测版本
    ...
  • v1.1.0.240910_9    v1.1.0在2024年09月10号第九次提测版本
  • v1.1.0.240910_91  v1.1.0在2024年09月10号第十次提测版本

当本次产品功能迭代测试结束,将v1.1.0归档为产品库中的标准正式版本,其它的都是迭代测试版本

4.版本号反例

  • v1.1.0.240910_1    v1.1.0在2024年09月10号第一次提测版本
  • v1.1.0.240910_2    v1.1.0在2024年09月10号第二次提测版本
    ...
  • v1.1.0.240910_9    v1.1.0在2024年09月10号第九次提测版本
  • v1.1.0.240910_10  v1.1.0在2024年09月10号第十次提测版本(错误版本)

错误说明:没有保证版本串按ASCII值排序,会导致线上获取最新版本错误等异常

5.团队大迭代版本定义

  • 旧项目迭代支撑版本前缀定义: v1.2.0.xxxxxx_x
  • 某大项目新功能A迭代分支版本前缀定义: v1.3.1.xxxxxx_x
  • 某大项目新功能B迭代分支版本前缀定义: v1.3.2.xxxxxx_x

相关文章

数据库事物,数据一致性的基石
解决Docker Hub镜像超时困扰
听歌搜歌下歌,尽在MusicFree
线上PostgreSQL锁表故障分析
PostgreSQL创建外部表场景及使用
vim常用命令

发布评论