When to increment build number?

Question

I'm reading a book which says:

The third number, 719, indicates the build of the assembly. If your company builds its assembly every day, you should increment the build number each day as well.

so it means to increment build number when you recompile the source code e.g. when you modify the source code.Then of course the build number is a relatively large number as we recompile our source code a lot of times.

But according to this https://docs.microsoft.com/en-us/dotnet/api/system.version?redirectedfrom=MSDN&view=net-5.0 which says:

Build: A difference in build number represents a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.

the "same source" means there is no code change, so build number shouldn't be incremented when the source code stays the same. If this is the case, we shouldn't be seeing a very large build number such as 719 as processor, platform, or compiler changes are very rare, a number like 3,4 is more sensible.

So do we need to increment the build number when the source code changes?

Answer 1

So do we need to increment the build number when the source code changes?

No, you need to increment it when you build the application. Build numbers increment per build. That's why it's called a build number.

Generally speaking, builds refer to compilations done by a dedicated build agent, and it does not include any local compilation a developer may do on their machine while trying to debug the application.

Additionally, build agents are generally only directed to start a build if any changes were made, or when manually told to build. It makes no sense to rebuild something that hasn't changed.

Even if you only build daily, I expect build agents to be configured so that they only start the daily build if anything has been committed since the last daily build.

That being said, in the olden days where application installs were still done by having a developer compile and copy the output to a production server, it was customary for each build to increment said build number.

---

"Different build numbers might be used when the processor, platform, or compiler changes."

... so build number shouldn't be incremented when the source code stays the same

You're saying the exact opposite of the information you just referenced.

---

Then of course the build number is a relatively large number as we recompile our source code a lot of times.

I think you are vastly overestimating how many builds you're going to be doing, or undervaluing how much builds can be housed in a number with relatively few digits.

Even if you build for every compilation, and compile the application every single minute, 24/7, it would take just under 70 days for it to become a six digit number. To reach a seven digit value, it takes about two years total.
Accounting for 8 hour work days, that's 210 days to reach six digits, and almost 6 years to reach 7 digits.

If you reduce it to hourly builds, and you assume that every hour (remember, 24/7!) you make a change, it takes 11.4 years for the build number to reach a six digit figure. It would take 114 years to reach seven digits.

On top of that, whenever the major/minor version is changed, the build number should reset. Depending on how often you release minor updates, this naturally caps how large a build number can get.

The amount of time it takes to add an extra digit to a number increases exponentially (10^{amount_of_digits}, to be precise).

I can keep doing the math on how long it takes for big numbers to get big, but I think I've made my point.

Answer 2

In a typical setup, build numbers are used when you have a central server that builds your software (often as part of a Continuous Integration pipeline). Those builds are then done periodically and/or when a change in the repository is detected.

In such a setup, the build number is provided by the build server and will increase for each build that the server makes for a particular build job.

Answer 3

You increment the build number each time a different build is seen outside your computer. For example, if you give a new build to QA it you increase the build number. If you are an automatic build system, you increase the build number. Yes, if you change the compiler, you treat that as a change of your source code.

The idea is that any two builds outside your computer with the same build number are identical.