版本号名称规范的常用或类别是什么?

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 收到显着变化等

次要 = 添加新的小功能或主要修复时。

修订 = 发布错误修复,但没有新功能。