Why do we increment build number every time even for nightly build?

The use is to distinguish the different builds.

Up vote 1 down vote favorite share g+ share fb share tw.

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.

Msbuild build build-process build-automation link|improve this question asked Jan 10 at 9:18SamJ111.

The number creates an identity of the build. – wilx Jan 10 at 9:22.

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: There have been changes in the code You want to do something with the build (I assume, test the changes) 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.

Why do we need to differentiate each and every day build. The number of increments will be more. Isn't it?

How to track particular day build using version number if many version numbers are there? – SamJ Jan 10 at 9:59 You are doing builds for two reasons there have been changes in the code AND second you want to do something with the build (I assume, test the changes). 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. – stema Jan 10 at 10:10 1 @stema I find your last comment a much more thorough answer than your original answer ;-) you should consider adding it up to it where it is more prominently seen. – Christian.

K Jan 10 at 12:04 @Christian. K OK I added it to the answer. It has been so obvious to me, but maybe its good to explain why you need to distinguish the builds.

– stema Jan 10 at 12:11.

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 don't 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.

1 "If I check in on changeset 45678 the build is 1.2.45678 (where your major minor version is 1.2). " - this is wrong design. We were using the same build numbering, but we changed it because build number is 16bit number.

If you reach more than 65535 changesets your build will fail. If you are working on the huge project or if your TFS contains a lot of projects you will reach this number soon. – Ludwo Jan 10 at 11:03 see the answer to that issue here:stackoverflow.com/questions/6121071/… – James Woolfenden Jan 10 at 14:51 yes it can be solved by using revision, but we are using revision for date stamp (mmdd format) – Ludwo Jan 10 at 15:08 Then you can have duplicate builds with different content?

Besides you already have the date stamped on every new folder and file. – James Woolfenden Jan 10 at 15:23 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 deploy builds and it is executed 2 times per day. 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 build version your projects will be rebuild.

– Ludwo Jan 10 at 15:36.

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.

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.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.