Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
    
Then you could use the date as the build number! –  user1249 Nov 23 '11 at 15:12
    
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 2.2.12.0 but the released build might be 2.2.8.0 and when you need to hotfix that, you pull source code for 2.2.8, revise it, and build 2.2.8.1, 3 months later current is 2.2.16.0 but one customer is still on 2.2.8.1 and runs into another bug, you pull code for 2.2.8.1 and revise it to fix the bug, and release it as 2.2.8.2 –  Jimmy Hoffa Oct 25 '12 at 14:47
add comment

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), and 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.

share|improve this answer
    
+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. –  Steve Evers Dec 10 '10 at 16:18
    
+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 Dec 10 '10 at 16:19
    
Odd. I would expect revision being last to make the most sense - it's the number that will (probably) change the most. –  Izkata Mar 22 '12 at 20:03
    
@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 Mar 22 '12 at 20:10
    
@tcrosley I guess it's a case of unclear terminology. I was thinking of revisions in version control. –  Izkata Mar 22 '12 at 20:19
show 2 more comments

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.

share|improve this answer
3  
+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. –  Mason Wheeler Dec 9 '10 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. –  Wyatt Barnett Mar 22 '12 at 15:18
add comment

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:

major.minor[.build[.revision]]

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.

http://msdn.microsoft.com/en-us/library/system.version.aspx

share|improve this answer
1  
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 –  Jimmy Hoffa Oct 25 '12 at 14:39
    
+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. –  Thomas Eding Jun 26 at 20:13
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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 1.0.50.0 Team 2 is taking a build from time to time. Let's say they take the build from last week which is 1.0.43.0 and start using it. Team 1 advances to 1.0.51.0 when team 2 finds an issue in 1.0.43.0.

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

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

The last two digits are the total build number

1.01.2.1234

the build number is 2.1234 however most people will just use 1234 since the 2 part does not change frequently.

share|improve this answer
1  
The OP is asking what is the build number, not which is the build number in the revision ID. –  kiamlaluno Nov 25 '11 at 14:58
add comment

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.

share|improve this answer
add comment

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 1.2.3.100
  • commit number 4712: Bob modified feature B
  • commit number 4713: Alice fixed feature A (the "hotfix")
  • CI produces build 1.2.3.101

major.minor.revision.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 1.2.100.0
  • 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 1.2.100.1

major.minor.build.revision

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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