项目版本描述规则

2014-07-05 [2132] use regexp

项目版本描述规则

Version definition

1. 概述

团队内所有产品和项目的版本号均遵循此规则。

2. 原则

基于 Tom Preston-Werner 的 语义化版本2.0.0 构建本规则。

版本实现内外统一，方便宣传、开发、运营和发音。

3. 版本号

3.1 版本号组成

版本号由 X.Y.Z-P.C 五个部分组成。详解如下：

代码 名称 递增条件 递增方式 可用字符 备注
X 主版本号 做了大改动的时候递增 人为递增 [0-9]
Y 次版本号 做了一般改动的时候递增 人为递增 [0-9]
Z 协议版本号 客户端-服务端协议做了变动的时候递增 机器递增 [0-9] 服务端所有协议版本相加
P 先行版本号 描述产品发布的方式，详见 先行版本 人为递增 [ABR][0-9] 团队内部描述和讨论仅使用此版本号
C 编译版本号 客户端版本编译时候的版本 机器递增 [0-9a-z] 客户端git代码库提交sha码前6位，编译当时确定

3.2 正则表达式表达法（Perl风格）

使用下面的正则拆分版本号各部分

([0-9]+)\.([0-9]+)\.([0-9]+)-([ABR][0-9]+)\.([0-9a-z]{6})

3.3 先行版本

  • 公司内部版本Alpha，简称A。版本编号从1开始，顺序递增；
  • 局部开放的测试版本Beta，简称B。版本编号依赖Alpha；
  • 公开发行的版本Release，简称R。版本编号依赖Beta。

3.4 先行版本工作流

所有的功能增加和修改，都是从Alpha版本开始的。每次增加功能，都必须递增先行版本。先行版本必须顺序递增，不得跳过任何数字。

  1. 团队按照Ax版本的计划逐步完成、完善内部版本。在内部对每一个Ax版本进行测试。Ax版本存在的问题，记录存档后，放在Ax+1版本中解决。
  2. 根据运营需求，挑选计划中或以完成的Ax版本，封装为Bx版本，进行小范围的、面向运营的测试。Bx版本存在的问题，记录存档后，放在同版本Bx中解决，直至完善。
  3. 挑选完善的Bx版本，封装为Rx版本发行。若Rx版本存在问题，回返上一步骤直至解决，然后重新封装为Rx版本号发行。

3.5 版本号制定工作流

  1. 策划和开发部门提出增加或者修改功能的要求；
  2. 运营部门制定先行版本号P；
  3. 开发部门制定主次版本号X.Y；
  4. 编译包时自动生成协议协议版本号Z和编译版本号C。

4. 范例

发布日期 发布用途 版本号
1024年12月25日 内部测试演示 0.1.100-A1.679ABF
2048年1月6日 内部测试演示 0.1.120-A2.5114f8
2048年1月31日 小范围外部测试 0.2.160-A3.5617ae
2048年X月X日 玩家小范围外部测试 0.3.100-B4.5617ae
... ... ...
2048年X月X日 公测或封测 0.9.301-B15.5617ae
2048年XX月XX-1日 1服前的最后1个Beta版本 0.9.356-B29.5617ae
4096年XX月XX日 1服 1.0.356-R29.5617ae

5. 使用

  1. 团队内部会议中，仅使用先行版本号。
    例如：A3版，B30版
  2. 在游戏界面中，显示完整版本号；
  3. 对外宣传时，一般使用 X.Y.Z 版本号；如有必要，可加入先行版本号。
    例如： 1.0.130 ， 1.0.356-R29