为什么我们每次都会增加内部编号，即使是每晚构建？

Question

为每晚构建增加版本号有什么用？

在我们的项目中，只有在我们发布系统测试时才会增加内部版本号。

请有人澄清我。每天增加内部版本号的所有优点是什么。

Answer 1

用途是区分不同的构建。

如果有一些版本号相同，你想如何引用某个版本？

您正在进行构建有两个原因：

1. 代码中有变化
2. 您想要对构建做一些事情（我假设，测试更改）

因此，您需要记录更改和结果，如果出现问题，您需要参考正确的版本。如果你想知道已经做了哪些改变，你想要追踪问题就更容易了。

Answer 2

我更喜欢使用与更改而非日期相关的编号方案。 我通常使用具有编号变更集（Subversion - tfs）概念的SCM。

因此，构建和scm之间的链接得以维护，您不必记录正在运行的构建号，并且已经为您完成了标签。  如果我签入变更集45678，则构建版本为1.2.45678（其主要次要版本为1.2）。

我不打扰当天的关联版本号。它不是最好的方法。

Answer 3

我们使用的是major.minor.xyyyy.mmdd构建版本格式，其中x是保留的，yyyy是每小时递增一次的计数器。此格式仅用于部署版本，每天执行2次。应设置计数器增量值以确保唯一构建版本和major.minor版本生命周期（对于yyyy = 9999 = 9999hours）。例如，ClickOnce需要唯一的构建版本。当主要/次要版本更改（或新版本已分支）时，计数器设置为零。

对于普通版本（不用于部署脚本），我们使用的是major.minor.0.0构建版本。这对于增量构建是必需的，因为如果更改构建版本，则将重建项目。对于大型项目（在我的情况下为500+），这不是一个好主意，因为重建可能需要很长时间。

Answer 4

我建议将版本格式设置为 major.minor.hotfix.build ，这样可以灵活地在将来支持修补程序版本时为主要版本提供各种子版本。

'build'可以是一个增量，对于每个构建都会增加，以便测试团队识别构建，如果它们遍布全球，因为每个测试团队都需要最新的构建来验证新修复。另外，我们可以拥有活动分支更改列表，这样我们仍然可以轻松识别构建代码的哪一部分。