Answers:
没有标准，但是您应该以一种对您有意义的方式进行操作，并包含跟踪该构建可能需要的所有信息。我曾在一家基本上将其分解成这样的公司工作：
[主要内部编号]。[次要内部编号]。[修订版]。[包装]
即版本：1.0.15.2
主要版本号：表示游戏中的主要里程碑，从beta到发行版，从发行版到主要更新版，请递增。
较小的内部版本号：用于功能更新，大错误修复等。
修订：对现有功能进行的细微改动，小的错误修复等。
包：您的代码保持不变，外部库更改或资产文件更新。
合并的更改会滚动到最重要的更改。例如，如果您要递增次要内部版本号，则修订版和软件包都将重置为0。
即使定义了类别，对于在修订版本和次要内部版本号之间实际跨越的功能类型仍然存在歧义。由你决定。如果列出了每次增加之前需要实现的功能列表，那么您还将有一个计划可以遵循，但最终由您决定适合哪些类别。
据我所知，这还没有标准。实践会因公司，团队和项目而异：没有最佳实践之类的东西。最重要的不是实际的约定，而是每个人都遵守的事实。
也就是说，您提到的方案在已发布的游戏中非常普遍。1.0通常是金牌母版，修补程序将从此处开始：1.1、1.2 ...它也用于预发行客户版本，例如私有或公开Beta。
对于开发中的游戏，我很少看到使用此系统。通过其原子更改ID（例如Perforce更改列表编号）来引用构建更为常见。这对于其中所有内容（代码和资产）都存储在同一存储库中并且已经进行持续集成的中型项目特别有用。在这种情况下，同时具有原子更改号和版本号是多余的并且容易出错。某些版本将在质量检查之后提升为一个里程碑：alpha，beta，候选发布者以及如此标记。
对于大型项目，“游戏版本”的简单概念不再适用。您将拥有多个平台，SKU，语言，单人游戏模式，多人游戏模式等。然后，版本管理将成为一项全职工作（有时称为数据管理器 -这是Ubisoft术语，在其他地方可能会有所不同） ，标记方案将变得更加复杂，并且高度依赖于实际制作的游戏。