Welcome to MSDN Blogs Sign in | Join | Help

News

Decoding Office Build Numbers

Open the About dialog box in any Office program.  Near the top, you'll find the build number of the program you're using.

If you are using Office 2003, you'll probably see something like 11.5608.5606.  If you are using Office 12, you might see something like 12.0.3417.1005.  In earlier versions, you'll see something similar.

While these numbers may look like unintelligible garbage, in reality they can be used to tell interesting information about the version of Office you're using.


Numbers...

In Office 2003, the "11" that precedes the build number is simply to denote that Office 2003 was version 11 of Office.  Similarly, the 12 in Office "12" means... well, you get it.  Office XP was version 10, Office 2000 was version 9, Office 97 was version 8.  You get the idea.

The most interesting thing to watch for is the first 4-digit number you encounter.  In the examples above, 5608 and 3417.  These are what we refer to as the "build number."  Every few days during the development cycle, we compile all of the code in Office and turn it into a "build": essentially an installable version of all the work everyone's done up until that point.  Eventually, a build becomes "final" and that is the one that ends up on CDs and in the store.

The 4-digit build number is actually an encoded date which allows you tell when a build was born.  The algorithm works like this:

  • Take the year in which a project started.  For Office "12", that was 2003.
  • Call January of that year "Month 1."
  • The first two digits of the build number are the number of months since "Month 1."
  • The last two digits are the day of that month.

So, if you have build 3417, you would do the following math: "Month 1" was January 2003.  "Month 13" was January 2004.  "Month 25" was January 2005.  Therefore, "Month 34" would be October 2005.

3417 = October 17, 2005, which was the date on which Office 12 build 3417 started.

For Office 2003 and XP both, "Month 1" was January 2000.  So, the final build of Office 2003, 5608, was made on August 8, 2003.

If you look at Office 2003 build numbers, you will see two four-digit numbers, separated by a period.  The first of the two numbers represents the build number for the program you're using (such as Outlook.)  The second of the two numbers represents the build number for the core Office shared library (called MSO), which is shared by all programs.

The Office 12 dialog boxes actually show the application and MSO build numbers separately--they're both even labeled so that it's easy to tell them apart.  The Office 12-style build numbers (12.0.3417.1005) reveal another internal artifact of the way we do builds--something we call "dot builds."

Sometimes it's necessary to have two kinds of builds going on at once within the Office team.  Recently, our build lab has been making both "Beta 1" builds and "Beta 2" builds.  In order to ship a stable Beta 1, we have slowed the rate of code changes dramatically and concentrated on just crucial bug fixes.  At the same time, we need a place to check in all of the other work people are doing for Beta 2--but we can't have those changes coming in and wrecking the stability of Beta 1 at the last minute.

The solution?  The build lab makes two kinds of builds at once.  A specific build number is chosen, and that build "becomes" Beta 1.  In this case, 3417.  That doesn't mean that Beta 1 is done however.  As bug fixes are checked in, we make new versions of the 3417 build, each one with an increasing number as a suffix, separated by a period.  (A so-called "dot" build.)  So there would be a 3417.1, 3417.2, 3417.3, and so on until Beta 1 is ready to ship.  Subtract 1000 from the second 4-digit number in the About box to find the "dot build" number.  In the above example, 3417.1005 is the 5th "dot" build of our Beta 1 branch.

At the same time, the build lab continues to churn out Beta 2 builds on the normal daily schedule: 3423, 3425, etc.  So, internally, we can tell which build is which kind by the number it has.

Last point: once a product ships, the rules for build numbers become even more complicated and different.  So, if you have Service Pack 2 for Office 2003, you might see a nonsensical number like 6552 or something.  Don't worry about it, it's not tied directly to a date in the same way anymore.

Armed with this knowledge, you're ready to amaze the world with your secret ability to decode Office build numbers.

Posted: Friday, November 11, 2005 7:00 AM by jensenh

Comments

orcmid said:

Groovy! as my dentist once said as he held a difficult extraction up to the light, while I was thinking he may have gotten more of the gas than I did.

What a delight to see this broken down. I have been itching to do a pattern template on just this kind of thing, and your account is a wonderful source of how these schemes come to reflect repeated practice and a desire for consistency and accountability of deployment processes.

What a great arrival along with my morning coffee. Thanks.
# November 11, 2005 10:55 AM

Mr. Dee said:

I still don't get it, its not easy like the Windows builds. I say just do it like this.

If you compiled a build on November 11, 2005, Friday, 2:50 AM, just have 111105.05.2:50 Whats so hard about that? Does it need to have such complexity. Anyway, I shouldn't make something like this bother me since its not like there is some human dependency on it.
# November 11, 2005 12:31 PM

Rob said:

Very interesting. I have done the same thing with my build numbers for years.
# November 11, 2005 12:40 PM

tzagotta said:

I just cannot believe why these numbers have to be so complicated and so encoded. Why could there just be a build serial number assigned to each build, and an associated database entry? This way all the internal folks could look up information about the build. For outsiders, we just need to know higher number is newer, lower number is older. The actual values hold no other meaning, i.e., why do I care when my version of Outlook was built.
# November 11, 2005 1:02 PM

tzagotta said:

I guess my point is (which I forgot to make) is that the build numbers are too complicated and just confuse outsiders.
# November 11, 2005 1:03 PM

jensenh said:

tzagotta:

I think the answer is that you shouldn't have to recognize or use the build number. Right next to it, it says something like "Microsoft Word 2003 Service Pack 2" which should be enough for most uses.

The build number is more for internal use, product support use, and for "enthusiasts..." :)

But the point is well-taken, it is a bit complicated. There are reasons why... there are some parts I left out to simplify the article (such as why 1000 is added in one step) that do actually have a reason behind it...
# November 11, 2005 1:15 PM

Abigail said:

Have a little sympathy for Office devs! :) We have enough trouble remembering what day it is today, without having to then look up the latest build serial number in a database to see if we have the latest version.

The good news for you is that indeed, higher number means more recent (and we'll hope that means "better" too).
# November 11, 2005 1:32 PM

Mike Dunn said:

Do you ever do tricks with the numbers, like how Win 95 just "happened" to be build 950?
# November 11, 2005 2:07 PM

jensenh said:

Mike Dunn:

No tricks, just treats.
# November 11, 2005 2:21 PM

PatriotB said:

Build numbers have always been one of those "interesting" things for me. Everyone does them somewhat different, too.

Windows (NT at least) always seemed to use an honest, count-of-builds system. e.g. NT 3.51=1057, NT 4 = 1381, 2000 = 2195. Rumor has it that XP was artifically rounded up to 2600. But after that things got artificial. Windows Server 2003 was bumped up to the mid 3000's. Early versions of Longhorn continued where 2003 left off (e.g. 4051, 4074) but then were "reset" into the 5000s, where they remain today.

Visual Studio 6.0 used an interesting system. VC++ 6.0's tools have build number 8168. The 8 comes from 1998, and the 168 represents that the file was built on the 168th day of 1998.

Visual Studio 2005 and .NET 2.0 use a new date method (50727 for July 27, 2005).

And then there's minor version numbers. Does it represent a decimal together with the major number? (e.g. 1.0 -> 1.1 -> 1.11 -> 1.2) Or is a separate, incrementable number on its own? (e.g. 1.0 -> 1.1 -> ... -> 1.9 -> 1.10 -> 1.11) Microsoft has used both techniques: NT 3.5 was really 3.50, Windows 98 was really 4.10; however XP's 5.1 is most definitely NOT 5.10.

Fun stuff! :)
# November 11, 2005 4:33 PM

Andrew Eberhard said:

This may seem a rather naive question, but in the scenario where two beta builds exist, are developers fixing bugs in both code bases? I can easily foresee situations wherein the fix for beta 1 might be incompatible with beta 2. I ask because this is the sort of thing that we frequently encounter at my company (though it is with "web" code rather than "office" code). If office developers are indeed operating under this kind of system (in addition to the myriad different service pack builds they must maintain code for), they do indeed have my sympathy. ;-)
# November 11, 2005 10:44 PM

jensenh said:

Any fix that is taken into beta 1 is also usually taken into beta 2, but it is up to the developer to make the call.

There are times when we fix things in a more safe, band-aid way for beta 1 and then check the "real fix" into beta 2, where we will have more bake time to test it to make sure it's right.
# November 12, 2005 1:44 AM

Liu said:

Where does office 12 take it's cleartype settings from?
# November 12, 2005 4:45 PM

jensenh said:

asdf:

Per editorial policy, removed your comment that was unrelated to this post.

I will remove unrelated comments without warning in the future. Thanks.
# November 14, 2005 1:38 AM

//Rutger said:

Interesting, I've got Office 2003 with build number 11.6359.6360.

'The last two digits are the day of that month.'. So that would mean that the final build was made in day 60?
# November 15, 2005 7:12 AM

jensenh said:

Rutger:

No, it means you have a service pack build of Office which, as I mention, has different rules.
# November 15, 2005 12:52 PM

Robert te Kaat said:

You say: Every few days during the development cycle, we compile all of the code in Office and turn it into a "build"

Does that mean you don't have a DAILY build? Or does it mean that every product of the suite has its separate build and every few days the whole suite is build together?
# November 21, 2005 4:27 AM

jason kemp .ca said:

# March 19, 2006 7:01 PM

Fear and Loathing said:

I was inspired by a recent blog entry by Jeff Atwood here about how Microsoft versions their products

# February 17, 2007 4:03 PM
New Comments to this post are disabled
Page view tracker