我们最近转向了一个自动构建系统(内部的东西，还不是 Hudson 或 Teamcity)。
我们的版本存储在头文件中，并包含在一些 cpp 和资源文件中。它也被安装程序使用。
它的格式是 A.B.C.D 其中:
- A 多年未变。
- B 很少更改(主要版本)。
- C 随次要版本发生变化。
- 当新的次要版本(错误修复)交付给 QA 时，D 会发生变化。
到目前为止，负责构建新版本的人在开始构建之前手动递增 C/D(D 更常见)，然后 checkin 更改，然后开始构建。在那个人成功构建应用程序之前，版本保持不变。
自然地，随着转向自动构建系统，我想摆脱更改版本号的手动步骤。
应该如何处理？
- 无论是 QA 构建还是内部测试构建(即我正在研究某些功能，我想测试我还没有)，我是否会在每次创建新构建时增加
D'打破任何东西)？ - 增量步骤是自动构建系统中的任务吗？
- 自增后是否要提交版本文件？
- 如何避免在我的版本控制中出现大量干扰？我不想要大量的“版本递增”提交。
- 如果构建失败我该怎么办？仍然增加版本并提交？
最佳答案
Do I increment D whenever a new build is made, whether it's a QA build or an internal-test build (i.e. I'm working on some feature and I'd like to test I haven't broke anything)?
Eclipse 基金会添加了一个 E 元素，即构建的日期和时间。我认为这对于内部测试版本来说是个好主意。是否要将 E 用于 QA 构建取决于您。
Is the increment step a task in the automatic build system?
看起来合乎逻辑，但您必须通过某种方式告诉该任务您正在执行何种构建。
How do I avoid having a lot of noise in my version control? I don't want tons of "version incremented" commits.
提交带有源代码的版本控制文件。
基本上，您的开发构建过程应按以下顺序进行。
- 从开发源代码构建产品。
- 如果构建成功，增加版本号。
- 提交源代码和版本控制文件。
- 从您的版本控制系统重新构建产品。
- 如果构建失败，撤回源代码和版本控制文件提交。
这会测试您的构建和构建过程。第二次构建应该永远不会失败，但如果失败，则过程中存在问题。
您的生产构建过程将从第 2 步开始，跳过第 3 步。
What do I do if the build failed? Still increment the version and commit?
我的 E 是自动递增的。 :-) 我会拒绝其他元素 A、B、C 或 D。
关于c++ - 使用自动构建系统进行版本控制，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5007707/