What I think about Build Numbers is that whenever a new nightly build is created, a new BUILDNUMBER is generated and assigned to that build. So for my 7.0 version application the nightly builds will be 7.0.1, 7.0.2 and so on. Is it so? Then what is the use of a REVISION after the build number? Or is the REVISION part being incremented after each nightly build? I am a little confused here... do we refer to each nightly build as a BUILD?

The format is mentioned here: AssemblyVersion - MSDN

  • Then you could use the date as the build number!
    – user1249
    Commented Nov 23, 2011 at 15:12
  • 4
    Build: Each new build of the system, Revision: Hotfix or "revision" of a released Build, thus why it alters the Build version; You're current build might be but the released build might be and when you need to hotfix that, you pull source code for 2.2.8, revise it, and build, 3 months later current is but one customer is still on and runs into another bug, you pull code for and revise it to fix the bug, and release it as Commented Oct 25, 2012 at 14:47
  • @JimmyHoffa, build number shall always increasing, so I am not sure your example make sens as you couldn't have,, as if you are at build 16 when fixing previous 2.2 release you should obtain Also it doesn't make sens that if you persue development process you are still at 2.2 while you are at build 16 as you migth had create new feature so you shall be at least à Of course it entirely possible to have differents set of rules that lead to the version scheme you descibre...
    – Richard
    Commented Sep 10, 2020 at 18:02
  • 2
    @Richard the hotfix is meant to provide 'as little change as possible', just the fix, not all the changes since that original release, regardless of what they are. What Jimmy Hoffa is describing is being used in the industry. It's an important risk mitigation strategy. A customer may have important reason to not want the latest software and just wants the fix to the problem that affects his operation. So if was release under strict rules to a customer a T1 and at T2 you released, a customer may want a fix just over and its
    – PRouleau
    Commented Oct 22, 2022 at 1:39

12 Answers 12


I've never seen it written out in that form. Where I work, we are using the form MAJOR.MINOR.REVISION.BUILDNUMBER, where:

  • MAJOR is a major release (usually many new features or changes to the UI or underlying OS)
  • MINOR is a minor release (perhaps some new features) on a previous major release
  • REVISION is usually a fix for a previous minor release (no new functionality)
  • BUILDNUMBER is incremented for each latest build of a revision.

For example, a revision may be released to QA (quality control), and they come back with an issue which requires a change. The bug would be fixed, and released back to QA with the same REVISION number, but an incremented BUILDNUMBER.

  • +1: That's pretty much the way I've seen it everywhere else too. I've seen and liked how some companies just use a DateTime stamp for the BUILDNUMBER. Commented Dec 10, 2010 at 16:18
  • 7
    +1:The "MAJOR.MINOR.REVISION.BUILDNUMBER" form is understandable and makes sense. I saw the BUILDNUMBER.REVISION form on MSDN site (link updated in question) and it confused me totally.
    – A9S6
    Commented Dec 10, 2010 at 16:19
  • 1
    Odd. I would expect revision being last to make the most sense - it's the number that will (probably) change the most.
    – Izkata
    Commented Mar 22, 2012 at 20:03
  • 3
    @Izkata, actually the build number changes the most, as least the way we use it at my main contract right now that uses strict version control because we are making medical devices. An updated revision indicates that there has been a fix to the previous software, which needs to be tested by QA (Quality Assurance). This is a completely separate department that does extensive testing for three days (per FDA guidelines). If they find any issues, then additional code changes might be necessary requiring a new build (recompile and link) and then retesting, but the revision number stays the same.
    – tcrosley
    Commented Mar 22, 2012 at 20:10
  • @tcrosley I guess it's a case of unclear terminology. I was thinking of revisions in version control.
    – Izkata
    Commented Mar 22, 2012 at 20:19

The whole confusion stems from the different semantics that MS uses for "Build number" and especially "Revision". The terms just mean different things.

Most people (myself included) use a semantic version numbering scheme where you just get a higher BUILD number whenever you have to make a new build for whatever reason. For us, a hotfix is considered just another code change, and the BUILD part increases automatically with every CI run. Modules with same MAJ.MIN.REV are considered interchangeable, and the BUILD tells you which one is the most recent.

Incrementing REVISION, however, indicates a new permanent release branch, that's why we place it before BUILD. The downside of that approach is, that we might get the following sequence of events:

  • commit number 4711: Alice added feature A
  • CI produces build
  • commit number 4712: Bob modified feature B
  • commit number 4713: Alice fixed feature A (the "hotfix")
  • CI produces build


As you can see, the hotfix is not the only change contained in the next build, also Bob's modification become part of that build. If you want to stabilize the current branch, you may run into troubles as you never can't be sure whether or not Bob just added a bunch of bugs.

MS uses both terms differently. The BUILD number is not automatically incremented, instead it can be considered being kind of a release branch, to freeze the code used for a particular version of the code. The REVISION indicates additional "hot" changes applied to that BUILD branch. The sequence would therefore be as follows:

  • commit number 4711: Alice added feature A to trunk/master
  • Carl creates build branch 1.2.100
  • CI produces build
  • commit number 4712: Bob modified feature B in trunk/master
  • commit number 4713: Alice fixed feature A in the 1.2.100 branch
  • CI produces build


The term REVISION may refer to

  • a product revision (that's how most people use it)
  • a revision of a particular daily build (that's what MS does)

The key difference between the two processes is, whether or not you want the ability to apply hotfixes to CI builds and thus, at which point in the process the branch is made. This aspect becomes important when you want to be able to pick a particular build at any time after all the tests succeeded and promote exactly that version to the next official release of your product.

In our case the CI tool creates a repository tag, so we always have the necessary information ready to use, when needed. With SVN it becomes even simpler, because tags and branches are implemented exactly in the same way - a tag is nothing more than a branch located under /tags.

See also

From the FAQ section at TFS branching strategy:

In what branch should I fix the P1 (hotfix) ticket?

  • The P1 should be fixed in the branch that is closest to the code base running in Production. In this case the P1 should be fixed in the Prod branch. By applying the fix in any other branch and rolling out the changes to production you risk releasing semi-finished or untested code from the subsequent iterations.

  • Now you may argue if it is safe to work directly against the Prod branch, think again, a P1 that requires immediate attention should not be a fundamental problem in the system. In case it is a fundamental problem it should be added to the Product backlog as it may require further analysis and discussion with the customer.

Another good read is the TFS branching guide


Microsoft describes the purpose of each component of a .NET version number in their MSDN documentation for the Version class. Here is the relevant portion:


The components are used by convention as follows:

Major: Assemblies with the same name but different major versions are not interchangeable. A higher version number might indicate a major rewrite of a product where backward compatibility cannot be assumed.

Minor: If the name and major version number on two assemblies are the same, but the minor version number is different, this indicates significant enhancement with the intention of backward compatibility. This higher minor version number might indicate a point release of a product or a fully backward-compatible new version of a product.

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.

Revision: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. A higher revision number might be used in a build that fixes a security hole in a previously released assembly.


  • 15
    It baffles me why no one knows this standard, every answer here claims build goes at the end and doesn't understand revision is very simple; it means hotfix. You release a build, and then create further builds, but when you have to go back and fix that release you update the revision to show the particular build which was released was altered for a new release Commented Oct 25, 2012 at 14:39
  • 2
    +1 for an answer that has a justifiable build number. Merely incrementing the number is rather useless if the revision stays the same (unless you have an insane build system that is time dependent). Using the build number to signal what compiler, platforms, etc is useful. Commented Jun 26, 2014 at 20:13
  • 3
    Build as a recompilation of the same source seems to be an important point that is missed. If it's a code change (that doesn't require a whole new Major/Minor increase) then the Revision must also be changed.
    – PeterX
    Commented Sep 8, 2015 at 9:01
  • 3
    "A difference in build number represents a recompilation of the same source" seems to contradicts the documentation. Once you make a revision, its no longer the same source. Having BUILD before REVISION makes sense only if a revision is specific to a build representing a "processor, platform, or compiler change". So I guess what most see as a REVISION bump should really be a MINOR bump when using these descriptions. Though the docs mention using REVISION for hotfixs, but Id assume hotfixs would apply to all builds, and should therefore be a MINOR bump. I just want some logical consistency!!
    – br3nt
    Commented Feb 9, 2020 at 23:59
  • 1
    The quote can now be found here.
    – robsch
    Commented Apr 5 at 12:56

There are at least a couple different things that I could imagine the build number referencing:

  1. Source control version that was release. For example if there was a release of revision #12345, this may be tracked by having it be the build number and if it is patched that is where revisions may go up as it isn't new functionality that would increase the major or minor versions and the build number has to be remembered in case someone wants to run that build again.

  2. Continuous integration server Identifier. In this case, the CI server may number each build it runs and thus the build number is what a successful build gets and the revision part isn't needed in this scenario.

There may be others that I don't know, but these are the big ones that I know when it comes to numbers on code bases.

  • 5
    +1 for #1. I like using the source control revision #, because it makes it that much easier to look up bugs reported against that version in source control. Commented Dec 9, 2010 at 18:49
  • @MasonWheeler : works great if you are on SVN. But when you get to dcvs land it gets squirrely. This would be one thing I miss most about svn I'll add. Commented Mar 22, 2012 at 15:18

A build number is usually incremented at every build so it is unique.

For simplicitys sake, some reset the build number whenever the MAJOR or MINOR numbers are bumped.

Most Continuous Integration engines allow for autogenerated unique build numbers.


The revision can be used for patches of the builds. Lets say that 2 teams work on a product.

Team 1 is the major development team and produces nightly build with the following version schema 1.0.X.0, where X is incremented. Now they are at build Team 2 is taking a build from time to time. Let's say they take the build from last week which is and start using it. Team 1 advances to when team 2 finds an issue in

Now team 1 will take that build (43), fix the issue and provide team 2 with the build The fix might be also propagated in the main build, so the change will appear in

Hope this is clear and helpful.

*Revision is useful when not everyone involved in the project uses the same build and you need to patch specific builds.


Let me just say how I see and use it....

ProgramName version major.minor.build.revision

major: For me is the current project I am working on. The number will not change until I start a new project of the same program name. This means I will literally be writing a new program of the same gender (example: access v1 - access v-2 - access v-3 * all the same program but completely rewritten).

minor: This means I am adding functionality to the current published project. For example maybe I added the ability to print a receipt or added the ability to import pictures. Basically additional functionality I want to add now and not wait for the next major release to do it.

build: This I use to indicate very small changes in the published major.minor version. This could be a change in the layout, colour scheme, etc.

revision: This I use to indicate a bug fix in the current published major.minor.build - There are occasions where I am not progressing the current project and a bug arises. This bug needs to be fixed and published. It just means I am fixing what I already published to work properly. I would also use this if I am working on a new build, a new addition or started a new major version. The published version obviously needs to be patched while we are waiting for the next major, minor or build release.

So in this manner a finished or stalled project can still be fixed and made useable until the next release is published.

I hope this gives someone a better understanding of how this type of versioning would (or should) work. To me it is the only definition and practice that makes any type of real sense when using this type of versioning.


I've only ever seen a build number as the last number in the release ID. I'm not sure how you'd come up with a revision to a build number. I suppose if you changed some of the non-built resources (icons, DB script, etc), maybe, but most projects I've worked on recently have all that stuff under version control as well, so the build process picks them up when making the installer/release. I like time-stamped build numbers, although not quite as @David describes (I like major.minor.revision.HHMM). However, where I work, we just use a sequential number that our build server generates.


Our team uses the third number (revision) as the revision number from the Subversion repository. We use the fourth number (build) as the build number from our TeamCity continuous integration server which actually creates the build. TeamCity creates a new AssemblyInfo file with the right #s in it during the build process.


Like jkohlhepp, we use the third part of the version to show the revision number in SubVersion and the fourth to show the build number from our continuous integration server (Jenkins for us). This gives us a several benefits - having the version number set by our CI server removes a manual step that could otherwise be accidentally missed; it's easy to check that a developer hasn't done a cheeky release from their development PC (which would result in these numbers being zero); and it allows us to tie any piece of software back to both the code that it was generated from and the CI job that built it, just by looking at the version number - which we occasionally find very useful.


I'm surprised nobody seems to have mentioned this. Whether a good idea or not, I've seen projects use the automagic build+release version numbering that MS provides. And what that does (is non-reproducible builds):

The AssemblyVersionAttribute attribute allows you to specify an asterisk (*) in place of the build or revision number. A version number such as [assembly:AssemblyVersion("1.2.*")] specifies 1 as the major version and 2 as the minor version, and accepts the default build and revision numbers. A version number such as [assembly:AssemblyVersion("1.2.15.*")] specifies 1 as the major version, 2 as the minor version, and 15 as the build number, and accepts the default revision number. The default build number increments daily. The default revision number is the number of seconds since midnight local time (without taking into account time zone adjustments for daylight saving time), divided by 2. If you specify an asterisk for the build number, you can't specify a revision number.


Use of the AssemblyVersionAttribute attribute that specifies an asterisk:

  • Makes the build outputs non-reproducible (see Reproducible builds). If the project sets Deterministic build property to true an error CS8357 is reported by the compiler.
  • Might degrade build performance, as it prevents build from caching compiler outputs.
  • Is incompatible with the Edit & Continue and Hot Reload features.

So that rather suggest MS wants to deprecate this automagic, but they didn't quite do it. OTOH they do say:

A better approach to versioning is to derive the assembly or file version from the HEAD commit SHA (for git repositories). See, for example, Nerdbank.GitVersioning.

By the way, the paras quoted by Cole Campbell's answer no longer appear in the current MS documentation at the link that answer provided. (The link is still valid, but suggestions about how to use those numbers are no longer in that API reference page.)


It is whatever you want it to be. I tend to use year.month.day.hhmm for my major.minor.build.revision. If I'm producing more than one a minute, something's wrong. you can just use a simple increment, or I've seen some elaborate generators for them. What do you want it to be. What they need to do is make it so you get to the source used to create that output, so whatever enables you to do that.

  • This was answered way before semver, please use that
    – BlackICE
    Commented Jul 17, 2023 at 13:58

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