游戏客户端的版本号目前主流都是四段式a.b.c.d，但是和传统的软件版本号不同的是，游戏客户端的版本号常常是由两部分组成的：分别为程序版本号(AppVersion)和资源版本号(ResVersion)。因为不同于传统软件，游戏软件的运营需要快速更新迭代游戏内容，而如果每次更新客户端都要重新安装，对于玩家来说体验不佳，对于游戏开发商来说也很麻烦(尤其是手游，需要提交到各应用商店审核)。所以在需要发布新的游戏版本内容时，游戏客户端的更新策略更倾向于仅热更新游戏资源(即保持程序版本号不变，仅更新资源版本号)，只在必要的时候才会更新程序版本号。

四段式版本号

无论AppVersion还是ResVersion均采用四段式a.b.c.d：

a: 主版本号(major version)
b: 次版本号(minor version)
c: 运营版本号(patch version)
d: 构建版本号(build version)
  • 主版本号
    主版本号是表示项目研发阶段的版本号，AppVersion和ResVersion共用同一个主版本号。
    • 处于研发阶段(未发布未上线)时为0
    • 处于内部测试阶段的项目(已发布未上线)时为1
    • 处于公测阶段的项目(已发布已上线)时为2
    • 之后每当进行一次”巨大改动”时，主版本号+1

      所谓”巨大改动”往往是架构层面的升级，或是对项目玩法和表现等进行颠覆性的升级

  • 次版本号
    次版本号是表示项目程序的版本号，AppVersion和ResVersion共用同一个次版本号。
    • 每当进行一次程序发布后，次版本号+1
  • 运营版本号
    运营版本号是表示项目资源的版本号，AppVersion和ResVersion共用同一个运营版本号。但是对于AppVersion来说运营版本号固定为0(因为每次程序发布后运营版本号会重置为0)；对于ResVersion来说运营版本号表示项目资源的版本号，重置时从1开始计数。
    • 每当进行一次资源发布后，运营版本号+1
  • 构建版本号
    一般由CI工具管理，AppVersion和ResVersion各自独立管理构建版本号。
    • 每当进行一次程序构建前，AppVersion的构建版本号+1
    • 每当进行一次资源构建前，ResVersion的构建版本号+1

      在该规则下，对于一个游戏客户端项目，一共需要维护五个基本版本号，分别是主版本号、次版本号、运营版本号、程序构建版本号和资源构建版本号，AppVersion和ResVersion的四段式版本号由上述基本版本号组合而成。

其它规则

  • 主版本号和次版本号相同的程序版本和资源版本必须是兼容的(仅限发布的正式版本)，但是主版本号或次版本号不相同的程序版本和资源版本也不一定不兼容，规则上不对此做限制。原则上程序版本和资源版本互相都有可能向上或向下兼容，开发者不必保证发布出去的最新客户端程序版本和资源版本的主版本号和次版本号一致，但是必须保证二者兼容。

    如果一个AppVersion所包含的二进制代码可以正常加载和使用另一个ResVersion包含的所有资源，那么该AppVersion和该ResVersion就是”兼容”的。

  • 资源版本和程序版本均可以独立构建或发布，互不影响。
  • 标记版本号的资源版本或程序版本发布后，就禁止改变该版本的内容，任何修改都必须以新版本发布。
  • 其中任意版本号+1时，所有比其低位的版本号均要重置计数。
  • 一般来说版本号的位数越高，其增加时变动的内容越多。
  • 出于尽可能少对外暴露细节的考虑，正式版本的AppVersion和ResVersion可以只展示三位版本号(隐藏构建版本号)，因为发布的正式版本号前三位和构建版本号是一一对应的。当然也有的项目为了方便测试和接收玩家反馈，统一展示完整的四位版本号。