# 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.

1. orcmid says:

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.

2. Mr. Dee says:

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.

3. Rob says:

Very interesting. I have done the same thing with my build numbers for years.

4. tzagotta says:

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.

5. tzagotta says:

I guess my point is (which I forgot to make) is that the build numbers are too complicated and just confuse outsiders.

6. jensenh says:

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…

7. Abigail says:

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

8. Mike Dunn says:

Do you ever do tricks with the numbers, like how Win 95 just "happened" to be build 950?

9. jensenh says:

Mike Dunn:

No tricks, just treats.

10. PatriotB says:

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! ðŸ™‚

11. 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. ðŸ˜‰

12. jensenh says:

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.

13. Liu says:

Where does office 12 take it’s cleartype settings from?

14. jensenh says:

asdf:

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

I will remove unrelated comments without warning in the future. Thanks.

15. //Rutger says:

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?

16. jensenh says:

Rutger:

No, it means you have a service pack build of Office which, as I mention, has different rules.

17. 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?

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