软件的版本号将类似于2.0.0.1 每个数字的规则是什么？ 在什么情况下，这个数字会加一个？
答案 0 :(得分：2)
Semantic versioning。我先读完了。大多数采用某种形式，如：
<major>.<minor>.<patch>
或
<major>.<minor>.<patch>-<qualifier>-<build number>
基本规则的简短摘要：
给定版本号MAJOR.MINOR.PATCH，增加：
- 当您进行不兼容的API更改时的MAJOR版本，
- 以向后兼容的方式添加功能时的MINOR版本，
- 当您进行向后兼容的错误修复时的PATCH版本。
预发布和构建元数据的附加标签可作为MAJOR.MINOR.PATCH格式的扩展。
然后 - 就像任何事情一样 - 讨论一些细节。这不是数学。营销部门通常涉及主要版本与次要版本。无论如何，这个页面可以很好地阅读： What version numbering scheme to use?
答案 1 :(得分：2)
这个名为Semantic Versioning的网络文档尝试对此进行标准化，但它实际上从来都不是一种方法。
如果您有发布周期，我认为增加主要/次要部分以反映这一点是合理的，但在这种意义上的版本化可能已成为过去。
今天，我发现（通常不是这样）源控制机制用于标记带有版本号的代码库。
过去只有一个版本号，但后来采用了像rev 2015.2.12.2293这样的版本控制方案，第一部分显然是一个日期，最后一个数字可能是一个版本号。这只是一个递增整数，可以唯一标识您拥有的构建。这要求您拥有构建最终版本的构建服务器，但是当您这样做时，您可以跟踪/跟踪您生成的所有内容，这就是我们使用版本的原因。
另一种方法是将Git提交SHA-1构建到代码中。它将允许您调出用于构建应用程序的确切状态（假设所有内容都驻留在Git存储库中）。虽然SHA-1版本有点长，但您可以使用标签或某些外部数据库来跟踪哪个SHA-1是哪个版本号。
答案 2 :(得分：1)
通常只使用三个数字Major.Minor.Revision / Patch。
...一般
Major =当添加了大量新的功能时，底层核心的变化足以使以前版本的软件与新版本的输出文件不完全兼容，或者UI会收到重大变化，等
Minor =添加新的小功能或主要修复时。
Revision =发布错误修复时，但没有新功能。