版本号名称规范的常用或类别是啥？

Posted 2023-03-05

【中文标题】版本号名称规范的常用或类别是啥？

【英文标题】：What is the common used or category of version number name specification?版本号名称规范的常用或类别是什么？

【发布时间】：2015-02-13 06:36:15

【问题描述】：

软件的版本号类似于 2.0.0.1 每个数字的规则是什么？ 什么情况下数字会加一？

【参考方案1】：

Semantic versioning 经常被使用。我会先读那个。大多数采用某种形式，例如：

<major>.<minor>.<patch>

或

<major>.<minor>.<patch>-<qualifier>-<build number>

包含基本规则的简短摘要：

给定版本号 MAJOR.MINOR.PATCH，增加：

当您进行不兼容的 API 更改时的主要版本， 以向后兼容的方式添加功能时的次要版本，并且 当您进行向后兼容的错误修复时的 PATCH 版本。

预发布和构建元数据的附加标签可用作 MAJOR.MINOR.PATCH 格式的扩展。

然后——就像任何事情一样——讨论一些细节。这不是数学。营销部门通常涉及主要版本与次要版本。无论如何，这个页面可以很好地阅读： What version numbering scheme to use?

【参考方案2】：

有一个名为 Semantic Versioning 的网络文档试图将其标准化，但实际上从来没有一种方法可以做到这一点。

如果您有发布周期，我认为增加主要/次要部分以反映这一点是合理的，但这种意义上的版本控制可能已成为过去。

今天，我发现（经常如此）源代码控制机制用于在代码库上标记版本号。

SO 过去只有一个修订号，但后来采用了类似rev 2015.2.12.2293 的版本控制方案，第一部分显然是日期，最后一个数字很可能是内部版本号。这只是一个递增的整数，用于唯一标识您拥有的构建。这要求您拥有构建最终版本的构建服务器，但是当您这样做时，您将能够跟踪/跟踪您生成的所有内容，这就是我们使用版本的原因。

另一种方法是将 Git 提交 SHA-1 构建到代码中。它将允许您调出用于构建应用程序的确切状态（假设所有内容都驻留在 Git 存储库中）。虽然 SHA-1 对于版本来说有点长，所以您可以使用标签或一些外部数据库来跟踪哪个 SHA-1 是哪个内部版本号。

【参考方案3】：

通常只使用三个数字 Major.Minor.Revision/Patch。

一般...

Major = 当大量新功能添加时，底层核心发生了足够大的变化，导致以前版本的软件无法与新版本的输出文件完全兼容，或者 UI 发生重大变化，等等

Minor = 添加新的小功能或重大修复时。

Revision = 发布错误修复，但没有新功能。