版本号名称规范的常用或类别是什么？
What is the common used or category of version number name specification?
一个软件的版本号会像2.0.0.1
每个数字的规则是什么？
什么情况下数字加一？
Semantic versioning 的使用频率很高。我会先读那个。大多数采用某种形式，例如：
<major>.<minor>.<patch>
或
<major>.<minor>.<patch>-<qualifier>-<build number>
具有基本规则的简短摘要：
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
然后 - 就像任何事情一样 - 对一些细节进行了讨论。这不是数学。营销部门通常会参与主要版本与次要版本的比较。无论如何，这个页面可以很好地阅读：
What version numbering scheme to use?
有一个名为 Semantic Versioning 的网络文档试图对此进行标准化，但实际上从来没有一种方法可以做到这一点。
如果您有发布周期，我认为增加 major/minor 部分来反映这一点是合理的，但从这个意义上讲，版本控制可能已成为过去。
今天，我发现（经常）源代码控制机制用于用版本号标记代码库。
SO 过去只有一个修订号，但后来采用了这样的版本控制方案 rev 2015.2.12.2293 第一部分显然是日期，最后一个数字很可能是内部版本号。这只是一个递增的整数，可以唯一标识您拥有的构建。这要求您拥有构建最终版本的构建服务器，但是当您这样做时，您将能够 track/trace 您生产的所有内容，这就是我们使用版本的原因。
另一种方法是将 Git 提交 SHA-1 构建到代码中。它将允许您调出用于构建应用程序的确切状态（假设所有内容都驻留在 Git 存储库中）。尽管 SHA-1 对于版本来说有点长，因此您可以使用标签或某些外部数据库来跟踪哪个 SHA-1 是哪个内部版本号。
一般只用三个号码Major.Minor.Revision/Patch.
一般...
Major = 当大量新增功能时，底层核心变化太大，导致旧版本软件无法完全兼容新版本的输出文件，或者类似UI 收到显着变化等
次要 = 添加新的小功能或主要修复时。
修订 = 发布错误修复，但没有新功能。
一个软件的版本号会像2.0.0.1 每个数字的规则是什么？ 什么情况下数字加一？
Semantic versioning 的使用频率很高。我会先读那个。大多数采用某种形式，例如：
<major>.<minor>.<patch>
或
<major>.<minor>.<patch>-<qualifier>-<build number>
具有基本规则的简短摘要：
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
然后 - 就像任何事情一样 - 对一些细节进行了讨论。这不是数学。营销部门通常会参与主要版本与次要版本的比较。无论如何，这个页面可以很好地阅读： What version numbering scheme to use?
有一个名为 Semantic Versioning 的网络文档试图对此进行标准化，但实际上从来没有一种方法可以做到这一点。
如果您有发布周期，我认为增加 major/minor 部分来反映这一点是合理的，但从这个意义上讲，版本控制可能已成为过去。
今天，我发现（经常）源代码控制机制用于用版本号标记代码库。
SO 过去只有一个修订号，但后来采用了这样的版本控制方案 rev 2015.2.12.2293 第一部分显然是日期，最后一个数字很可能是内部版本号。这只是一个递增的整数，可以唯一标识您拥有的构建。这要求您拥有构建最终版本的构建服务器，但是当您这样做时，您将能够 track/trace 您生产的所有内容，这就是我们使用版本的原因。
另一种方法是将 Git 提交 SHA-1 构建到代码中。它将允许您调出用于构建应用程序的确切状态（假设所有内容都驻留在 Git 存储库中）。尽管 SHA-1 对于版本来说有点长，因此您可以使用标签或某些外部数据库来跟踪哪个 SHA-1 是哪个内部版本号。
一般只用三个号码Major.Minor.Revision/Patch.
一般...
Major = 当大量新增功能时，底层核心变化太大，导致旧版本软件无法完全兼容新版本的输出文件，或者类似UI 收到显着变化等
次要 = 添加新的小功能或主要修复时。
修订 = 发布错误修复，但没有新功能。