我们最近转向了自动构建系统（内部，而不是Hudson或Teamcity） 我们的版本存储在头文件中，并包含在某些cpp和资源文件中。它也被安装人员使用。
其格式为A.B.C.D，其中：
到目前为止，在开始构建之前，建立一个新版本的一个支持者手动递增C/D（D更常见），检查更改然后开始构建。该版本保持不变，直到该人成功构建应用程序。
当然，随着转向自动构建系统，我想摆脱更改版本号的手动步骤。
应如何处理？
D，无论是QA构建还是内部测试构建（即我正在研究某些功能，我想测试我没有破坏任何东西）？答案 0 :(得分：1)
每当进行新的构建时，我是否会增加D，无论是QA构建还是内部测试构建（即我正在处理某些功能，我想测试我没有破坏任何东西）？< / p>
Eclipse Foundation添加了一个E元素，即构建的日期和时间。我认为这对于内部测试构建来说是一个好主意。如果您想使用E进行QA构建，这取决于您。
增量步骤是自动构建系统中的任务吗？
似乎是合乎逻辑的，但你必须有一些方法告诉那个任务你正在做什么样的构建。
如何避免版本控制中出现大量噪音？我不想要大量的“版本增加”提交。
使用源代码提交版本控制文件。
基本上，您的开发构建过程应按以下顺序进行。
这会测试您的构建和构建过程。第二个构建应该永远不会失败，但如果确实如此，那么这个过程就会出现问题。
您的生产构建过程将从第2步开始，跳过第3步。
如果构建失败，我该怎么办？仍然增加版本并提交？
我的E是自动递增的。 :-)我会对其他元素A，B，C或D说不。
答案 1 :(得分：1)
每当进行新的构建时，我是否会增加D，无论是QA构建还是内部测试构建（即我正在处理某些功能，我想测试我没有破坏任何东西）？< / p>
是的，更改您的流程，以便D随每次构建（成功与否）递增，而不是每次向QA递送。
有几个版本可能会非常令人沮丧，有些工作没有，并且无法区分它们，因为失败的构建与良好构建的id相同，最终也是如此。 那么你甚至不必考虑它是在同一天还是在同一时间。
增量步骤是自动构建系统中的任务吗？
我的构建系统只会自动增加内部版本号（D）。
递增后，我应该提交版本文件吗？ 如何避免版本控制中出现大量噪音？我不想要大量的“版本增加”提交。
版本控制存储就是记录详细的噪音。
我已经签入了版本更新，这可以在SVN中显示一个合理的标签，其中包含构建先前更改的内容，构建系统忽略构建系统的签入，或者标识为版本更新的那些签。
然后，要查看版本历史记录，您应该拥有一个合适的工具，允许您过滤历史记录以显示所需的视图，在某些情况下不包括版本提交标记。
如果您选择不为每个版本提交版本号，那么最好将版本号保存在单独的文件中以避免意外更新。
如果构建失败，我该怎么办？仍然增加版本并提交？
仍然增加版本号，我不会提交版本号，除非它是一个成功的版本。您可以在版本控制中更改源代码之外的各种故障，这些故障不需要记录 - 构建服务器磁盘不足，服务器崩溃，编译器在构建32位和64位，调试和释放aix的时候摇摇欲坠linux和windows同时构建......
答案 2 :(得分：0)
您可以考虑使用.NET程序集的约定，如class System.Version的文档中所述。引用：
- 构建 [您的C]：构建号的差异表示对同一源的重新编译。当处理器，平台或编译器发生更改时，可能会使用不同的构建号。
- 修订 [您的D]：具有相同名称，主要版本号和次要版本号但不同修订版的程序集应完全可互换。可以在修复先前发布的程序集中的安全漏洞的构建中使用更高版本号。
答案 3 :(得分：0)
你将如何实现自动化？我的意思是，什么系统会知道“这个版本是发布版本！”。在我看来，版本中的所有数字都是相关的。如果下一个版本（D + 1）需要两个版本，那么A.B.C.D + 2将成为下一个版本吗？对我来说听起来很腥。如果真的有必要在你的DLL和EXE上提供这些信息，我宁愿在版本之上添加构建号。
我不认为内部版本号是附加到二进制文件的相关信息，除非你从不同的版本中分发版本ABCD的文件（你不应该这样做！） ）
我会设置构建服务器将工件（DLL，EXE，MSI，PDB等）存储在一个目录中，该目录的名称包括内部版本号和版本，然后从那里刻录DVD /其他内容。如果您需要从版本回溯到特定版本，则可以使用此信息，前提是您保留了版本的存档（推荐！）。
答案 4 :(得分：0)
我建议使用autorevision。
您仍然可以保留标记的A.B.C.D格式，并使用该脚本创建在构建时生成的头文件，其中包含所需的信息。