为什么我们每次都会增加构建号，即使是夜间构建？
每晚构建增加版本号有什么用？
在我们的项目中，只有当我们发布它进行系统测试时，我们才会增加内部版本号。
请有人澄清我。每天增加内部版本号有哪些优点？
What is the use of incrementing version number for nightly build?
In our project we will increment build numbers only when we release it for system testing.
Please some one clarify me. What are all the advantages of incrementing build number everyday.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
用途是区分不同的构建。
如果某些版本具有相同的版本号，您希望如何引用某个版本？
您进行构建有两个原因：
因此您需要记录更改和结果，如果出现问题，您需要请参考正确的版本。如果您想追踪问题，如果您知道做了哪些更改，那就容易多了。
The use is to distinguish the different builds.
How do you want to refer to a certain build if there are some with identical version numbers?
You are doing builds for two reasons:
So you need to document the changes and the results and if there is a problem you need to refer to the correct version. If you want to track down problems its much easier if you know what changes has been done.
我更喜欢使用与更改而不是日期相关的编号方案。
我通常使用具有编号变更集概念的 SCM（Subversion - tfs）。
因此，构建和 scm 之间的链接得到维护，您不必保留正在运行的构建号的记录，并且标签已经为您完成。
如果我检查变更集 45678，则构建版本为 1.2.45678（其中主要次要版本为 1.2）。
我不会费心将内部版本号与当天联系起来。这不是最好的方法。
I prefer to use a numbering scheme that is connected with change and not date.
I usually use a SCM that has the concept of a numbered changeset (Subversion - tfs).
Therefore the link between a build and the scm is maintained and you dont have to keep a record of the the running build number and the label is already done for you.
If i check in on changeset 45678 the build is 1.2.45678 (where your major minor version is 1.2).
I wouldn't bother with relating build numbers to the day. Its not the best approach.
我们使用major.minor.xyyyy.mmdd构建版本格式，其中x是保留的，yyyy是每小时递增的计数器。此格式仅用于部署构建，每天执行 2 次。应设置计数器增量值以确保唯一的构建版本和主要.次要版本生命周期（对于 yyyy = 9999 = 9999 小时）。例如，ClickOnce 需要唯一的构建版本。当主要/次要版本更改（或新版本分支）时，计数器设置为零。
对于正常构建（不用于部署脚本），我们使用major.minor.0.0构建版本。这对于增量构建是必要的，因为如果您更改构建版本，您的项目将被重建。对于大型项目（在我的例子中超过 500 个）来说这不是一个好主意，因为重建可能需要很长时间。
We are using major.minor.xyyyy.mmdd build version format, where x is reserved and yyyy is a counter incremented every hour. This format is used only for the deploy builds and it is executed 2 times per day. Counter increment value should be set to ensure unique build versions and major.minor version lifetime (for yyyy = 9999 = 9999hours). Unique build version is required for ClickOnce for example. Counter is set to zero when major/minor version is changed (or new version is branched).
For normal builds (not used for deploy script) we are using major.minor.0.0 build version. This is necessary for incremental builds because if you change the build version, your projects will be rebuild. This is not good idea for large projects (500+ in my case) because rebuilding can take a very long time.
我建议版本格式为major.minor.hotfix.build，这提供了将来当我们想要支持修补程序版本时将各种子版本构建到主要版本的灵活性。
'build' 可以是一个增量，如果测试团队分布在全球范围内，则每个构建都会增加该增量，以便测试团队识别构建，因为每个测试团队都希望最新的构建来验证新修复。否则，我们可以拥有活动分支更改列表，以便我们仍然可以轻松识别构建具有代码的哪一部分。
I would recommend the version format as major.minor.hotfix.build, This provides the flexibility of having various sub-builds to a major release in future when we want to support hotfix releases.
'build' can be a increment which is incremented for every build for identification of the builds by the test teams if they are spread out across the globe as every test team wants the latest build to verify the new fixes. Else, we could have the active branch changelist so that we could still easily identify the build has what part of the code.