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

夜间构建的增量版本号有什么用处？为什么我们每次增加构建编号，即使是每晚构建？

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

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

来源

2012-01-10 SamJ

该编号创建构建的标识。 – wilx 2012-01-10 09:22:55

用途是区分不同的版本。

如果某些版本与某些版本号相同，您希望如何引用该版本？

你正在做的建立有两个原因：

代码

你想要做的事与构建

已经有变化（我假设，测试所做的更改）

所以你需要记录变化和结果，如果有问题，你需要参考正确的版本。如果你想知道发生了什么变化，那么你就更容易追踪问题。

来源

2012-01-10 09:26:15 stema

为什么我们需要区分每一天和每一天的构建。增量的数量会更多。不是吗？如果有许多版本号，如何使用版本号跟踪特定的日期版本？ – SamJ 2012-01-10 09:59:45

由于两个原因，代码中发生了变化，并且您希望对构建做些什么（我假设，测试这些变化），所以您正在进行构建。所以你需要记录变化和结果，如果有问题，你需要参考正确的版本。如果你想知道发生了什么变化，那么你就更容易追踪问题。 – stema 2012-01-10 10:10:24

@stema我发现你最近的评论比你原来的回答更彻底的答案;-)你应该考虑把它加到它更显眼的地方。 – 2012-01-10 12:04:11

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

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

我不会打扰到将内部版本号与当天相关联。它不是最好的方法。

来源

2012-01-10 10:43:52

“如果我在变更集45678中检入版本是1.2.45678（其中您的主要次要版本是1.2）”。 - 这是错误的设计。我们使用相同的内部编号，但是我们更改了它，因为内部编号是16位编号。如果您达到超过65535个变更集，您的构建将失败。如果你正在从事这个庞大的项目，或者你的TFS包含很多项目，你很快就会达到这个数字。 – Ludwo 2012-01-10 11:03:17

请参阅此问题的答案：http：//stackoverflow.com/questions/6121071/versioning-an-assembly-info-past-the-uint16-barrier – 2012-01-10 14:51:59

是的，它可以通过使用修订版来解决，但我们正在使用修改日期戳（mmdd格式） – Ludwo 2012-01-10 15:08:47

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

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

来源

2012-01-10 15:41:44 Ludwo

我会推荐版本格式为major.minor.hotfix.build，这为我们希望支持修补程序版本时在未来的主版本上提供各种子构建提供了灵活性。

“构建”可以是递增的每一个增量构建鉴定的被测试团队建立，如果他们在全球范围内为每一个测试团队希望最新版本，以验证新的修补程序展开。否则，我们可以拥有活动的分支变更列表，以便我们仍然可以轻松识别构建代码的哪部分。

来源

2012-02-17 06:38:58 msKing

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

回答

相关问题