大到操作系统,小到小程序,我们经常收到系统或者软件版本升级的通知。例如macOS、印象笔记的版本情况如下:
macOS的主版本从high sierras 到Mojve 再到Catalina。

印象笔记产品的版本关联了富文本编辑器、Markdown编辑器。

印象笔记产品版本号命名示例为Version9.2.0

软件版本阶段
一般情况下,软件可以分为四个阶段,需求规划阶段、研发阶段、提测阶段、试运行阶段、正式发布阶段。其中建议对提测、试运行、正式发布的软件版本进行管理,命名规则如下:
-
提测版 stg
该版本已经过内部测试,没有严重bug,可提交测试组进行测试。其中测试组提出的bug在bugfree中管理。
stgx表示提测时的版本号,x为奇数,起始数字为1;
stgy表示bug修改完成的版本号,y=x+1。 -
试运行版 beta
该版本已经经过测试组测试,基本不存在导致错误的bug,可以发布在正式环境中,进入试运行阶段,供用户试用。 -
正式版 release
该版本是最终版本,经过测试、试运行之后,正式交付用户使用。
命名规范
主版本号.子版本号 [.修订版本号] [.日期版本号] [_ 阶段版本号]
示例
2.10.15.191030_beta
2.1.2
2.6_beta
类型 | 说明 | 决策人 | 取值范围 |
---|---|---|---|
主版本号 | 功能模块有较大变动时,比如增加多个模块、增加重要模块、整体架构变化等 | 总负责人 | 0~9 |
子版本号 | 功能有一定的增加或变动,比如增加权限控制等 | 产品经理 | 0~99 |
修订版本号 | 功能的bug修复或者小变动,比如修复一个严重bug,页面的小优化等 | 技术负责人/产品经理 | 0~99 |
日期版本号 | 标注当前版本的日期 | 技术负责人 | 月份日期,例如191030 |
阶段版本号 | 标注当前版本的软件阶段。 | stg1:测试负责人; stg2:技术负责人; beta:产品经理; release:总负责人 | stg、beta、release |
基本原则
- 版本号一定顺次增长,数字增量为 1
- 主版本号增长时,子版本号、修订版本号清零;
- 一旦发布了版本,任何修改都必须发布一个新版本;
- 当功能变动能向下兼容时,一般增加子版本号;
- 当功能变动不能向下兼容时,建议增加主版本号;
版本说明
本次更新
发布时间:yyyy年mm月dd日
产品版本号:V***
版本说明:
概况
【新增内容】
- 新增xx模块/功能
- 新增xx模块/功能
【优化内容】 - 优化xx模块/功能,改进了xx体验/操作/展示
- 优化xc模块/功能,改进了xx体验/操作/展示
【修复内容】 - 修复xx模块/功能,修复了xx体验/操作/展示
- 修复xx模块/功能,修复了xx体验/操作/展示
版本依赖管理
xx系统xx模块,依赖xx系统xx模块
版本流程
版本发布前
- 规划发布的功能
- 编排版本发布计划
版本研发测试时
- 软件开发编码前,从当前主干分支中建立开发分支,在开发分支开发新功能
- 软件提测前,从当前开发分支合并测试分支,打stg版本标签
- bug分级,确认要修改的bug
- 在开发分支上进行bug修改,完成后,打stg版本标签
- 回归测试
版本发布时
- 保证软件版本稳定可靠,申请进行试运行阶段
- 申请通过后,软件代码合并到主要分支,打beta版本标签
- 在服务器上备份当前版本的代码
- 在服务器上部署新版本的代码
- 如果发布出现问题,回滚上一版本
- 发布完成后,通知相关人员版本更新内容,正式进入试运行阶段
- 如果有问题,收集用户使用问题,将问题分级,确认版本计划。
- 如果没有问题,一个月试运行结束后,进入正式发布阶段,在主分支打release版本标签
- 发布完成后,通知相关人员版本更新内容,正式进入正式阶段。
泳道图示意如下:
网友评论