Version numbers and those rascals at Microsoft

Posted under Blog Posts, Software Design

If you have electricity in your house, you are probably familiar with version numbers.  Software developers use version numbers to differentiate between different builds of the same application, and these version numbers are critical to our way of life.  Why on earth did Microsoft take it upon themselves to turn my world upside down!?

Different versions of software look remarkably similar when they run, so the only way for us to tell the difference is to label each version of the application with a number.  Ever since the second piece of ‘software’ was hammered out using tubes and switches, there has been a version naming/numbering scheme.  Over the years, a pattern evolved that is now widely accepted as the standard:

Major.Minor.Revision.Build

So what do the engineers at Microsoft do?  They change things up a bit!

Major.Minor.Build.Revision

Sure, this might have officially happened quite a while ago, but when I first saw this I thought they had turned some poor dyslexic intern loose with the documentation.  After some real digging, I found that this reversal was intentional.  See this official ECMA 335 standard document for the details.  How did I miss that memo?

If you think that I’m an idiot that should have known about this issue, please feel free to tell me so in the comments.  Also, I’d be interested in knowing how you first learned about the version number pattern.

To the non-programmer looking in from the outside, this change might seem insignificant.

Allow me to put forth a non-programmer example:  What if you relied upon my company for book publishing services, and I told you:

We are going to unilaterally change the order of the letters in the alphabet?  We are changing:

• Â
  • ABC
    to be…
  • ACB

All of the typos in your manuscripts over the past 4 months are due to this change, and are in fact not typos at all.  The discrepancies are the result of your lack of awareness of the change that was clearly documented in our June newsletter on page 563 in the section titled “Non-Important Stuff.”  As such, you are responsible for fixing all of the typos.

Also, we’ll be changing all of our keyboards, and charts, books, and spellchecker software over time, but NOT AT THE SAME TIME!  Also, we won’t be upgrading our typewriters because they are no longer covered by the product support lifecycle.  (If you still own a typewriter, why haven’t you upgraded yet?  You should have upgraded by now!  Here, buy our upgrade!)

We are a full Microsoft shop from head to toe, we have drank the Kool Aid, and are willing participants in the Microsoft economy.  We love their development tools and have admired their platforms and components ever since Server 2003 and XP.  We are with Microsoft for as long as our customers use Microsoft platforms. So, we have to understand, absorb, and grow to love this new version numbering scheme.

In all fairness, we might have been “working around” this issue for a long time, manually versioning our software according to the major.minor.revision.build scheme.  We just banged our heads into this new major.minor.build.revision scheme when we started dealing with ClickOnce and manifest encoding.

My team manages a growing number of very complicated system deployments across the country, and we use these version numbers to control “what goes where.”  After finally learning about this new Microsoft-initiated versioning scheme, our team spent a couple of hours in discussions and sent a bunch of e-mails related to the change. We finally have our heads around it.

Regardless of the initial reasoning behind the ECMA 335 versioning pattern, I personally expect Microsoft to change the scheme back again. I don’t know when it will happen, but my gut tells me things on a regular basis that ultimately turn out to be true.  My gut tells me that they know that they made a mistake.