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.
Comments
Anonymous
November 11, 2005
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.Anonymous
November 11, 2005
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.Anonymous
November 11, 2005
Very interesting. I have done the same thing with my build numbers for years.Anonymous
November 11, 2005
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.Anonymous
November 11, 2005
I guess my point is (which I forgot to make) is that the build numbers are too complicated and just confuse outsiders.Anonymous
November 11, 2005
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...Anonymous
November 11, 2005
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).Anonymous
November 11, 2005
The comment has been removedAnonymous
November 11, 2005
The comment has been removedAnonymous
November 11, 2005
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! :)Anonymous
November 11, 2005
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. ;-)Anonymous
November 11, 2005
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.Anonymous
November 12, 2005
Where does office 12 take it's cleartype settings from?Anonymous
November 13, 2005
asdf:
Per editorial policy, removed your comment that was unrelated to this post.
I will remove unrelated comments without warning in the future. Thanks.Anonymous
November 14, 2005
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?Anonymous
November 15, 2005
Rutger:
No, it means you have a service pack build of Office which, as I mention, has different rules.Anonymous
November 20, 2005
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?Anonymous
February 18, 2006
PingBack from http://rakheshshows.wordpress.com/2005/11/12/decoding-office-build-numbers/Anonymous
February 17, 2007
I was inspired by a recent blog entry by Jeff Atwood here about how Microsoft versions their productsAnonymous
February 17, 2007
PingBack from http://bagofbeans.tsangal.org/archives/328Anonymous
June 01, 2009
PingBack from http://paidsurveyshub.info/story.php?id=67713Anonymous
June 13, 2009
PingBack from http://ebeanbagchair.info/story.php?id=204Anonymous
June 16, 2009
PingBack from http://workfromhomecareer.info/story.php?id=13480Anonymous
June 18, 2009
PingBack from http://thestoragebench.info/story.php?id=1465