1

I'm reading a book which says: enter image description here

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?

5
  • 2
    "So do we need" - finding out what you and your team needs or prefers in versioning is up to you, and it will probably different from those Microsoft standards. Is your question specificially about how to interpret SemVer ? Then it would be clearer if you would ask exactly that. Note the Microsoft docs are just a rough suggestion how to use the four digits, they don't imply you are using SemVer. Note further SemVer is primarily for libraries or APIs, not necessarily for applications which just use such libs or APIs. – Doc Brown Jan 20 at 5:53
  • 2
    I'm pretty sure that "recompilation of the same source" means "recompilation of the code that is located in the particular source control system" and not "recompilation of identical set of files".... You are trying to find very deep meaning in the guidance - in reality all you need is to be able to find what source/parameters were used to build given version. Consumers of your assembly would be glad if you respect semver.org , but that's up to you. – Alexei Levenkov Jan 20 at 5:53
  • Microsoft often release variants of its software. like a variant for ARM, a variant for x86, another for x64, etc... Not to mention the different OS builds. Not all of these packages can be built simultaneously by one machine and they still need to track what was built, on what, when, etc... Figure out what you need from a versioning system and see what supports your organisation/team style. – Kain0_0 Jan 20 at 7:41
  • 1
    please don't cross post: stackoverflow.com/questions/65801203/… – gnat Jan 20 at 8:52
  • 1
    I see this is tagged with "semantic-versioning", but this question is about a completely different versioning scheme. Semantic Versioning has no concept of "build number". I don't know if the versioning scheme listed here has a name, but it's good to bear in mind that it's just one among many. – IMSoP Jan 20 at 16:35
4

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 (10amount_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.

1
  • AFAIK for .net assembly the version part is limited to 2**16, so 6 digits number is not really that little. – max630 Jan 20 at 13:04
4

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.