项目版本描述规则

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.1301.0.356-R29

留言

2014-07-05
次访问