Wednesday, September 6, 2006

What does "RC1" really mean?

With the recent release of Windows Vista RC1, I have seen many comments on places like Slashdot and various blogs which demonstrate there is a lack of understanding of what we mean when we say we have "Release Candidate 1".  I will attempt to explain what we mean when we say RC1.  This is not an exhaustive definition nor is it official but it should give you a good idea what we mean when we say it.

There is an impression that this is the build we intend to release as the final build unless something heinous bug is found in it.  That is often what the term release candidate means in the world of software but not here. 

Back when I started at Microsoft in 1997, we were in the process of releasing IE4 and then Windows 98.  In both of those cases, the release candidate builds were just that, candidates for release.  If we had RC1 on Monday and found a bug in it, on Tuesday we'd have RC2.  If we didn't find a bug on Tuesday but found one on Thursday, then Friday we would have RC3 and so on.  After a half-dozen builds or so, we would have a final release.

When I moved to the NT5 team (what became Windows 2000), it was confusing to me to hear the same terminology mean something very different.  In that world, and in the world of Vista today, what we call a release candidate is more of a waypoint on the way to release than a build we actually think will be the final one.  An RC build is one that we iterate on for a while to drive up the quality (like a beta or one of the CTP releases--only moreso).  A release candidate, in this way of thinking, is a build you release that will differ only in minor ways from the final one.  The bar for bugs goes up substantially after it.  We become really strict about what we will take for the product.  No new features or even major changes are allowed in.  Just bug fixes which don't perturb the system too much.  In this nomenclature, a "release candidate" is not really a candidate for final release.  We know there will be bugs to fix after we release it.  In the WinXP timeframe, there was a month or maybe even two between RC builds.  During that time we still had daily internal builds.  Each release candidate was closer to the final build and the amount of change allowed afterward was smaller than before.

So what do we call the builds we are really considering for release?  We usually call them escrow builds.


Update:  I found a nice chart in this Seattle PI article showing the time from RC1 to RTM for Windows 2000 and Windows XP.  For Windows 2000, it was 166 days.  For XP, it was 53.


  1. Sorry, but I still don't get the explanation.

    When you say that an RC is "like a Beta [...] only moreso" and "No new features or even major changes are allowed in.  Just bug fixes which don't perturb the system too much." - how is this different from a Beta?

    AFAIK, even for MS, when software reaches Beta, there are no new features or "major" changes to be added. Given that the criteria for what constitutes a "major" change probably gets tighter for each Beta anyway (I know it does where I work) - what actually makes the difference between a pre-release version being called "Beta n+1" and "RC1"? What exactly *is* the "only moreso"?

  2. In questo ultimo perido, il termine "RC1" impazza sulla rete. Merito di Windows Vista e del .NET 3.0

  3. Microsoft really think that they rule the world. Release Candidate means that there are no showstoppers that's it. It is not because you guys are from Microsoft that you should start to redefine everything. Talking about ubiquitous language.

  4. ya'know, if you stopped giving new meaning to terms, you wouldn't have to explain what you mean by them.

    Originally, "Beta" meant "release candidate" (literal meaning).  (ie, software was developed and tested at the "alpha site".  At the "Beta Site" was the "second set of eyes" test before release).

    When the term "Beta" evolved into "half-baked preview", we created a new term, "Release Candidate", to mean "release candidate".  

    Now, before we corrupt "Release Candidate" into meaning "feature complete preview" (forcing us to corrupt the meaning of another term -- "escrow build" -- to mean "release candidate"), why not just create a new term to mean "feature complete preview", say "Feature Complete Preview"?

  5. Adam, I didn't mean to imply that an RC is like a beta.  What I intended to be saying is that it was a particular build that we iterated on to drive it to quality.  This is the same process we use for a beta or one of the interim CTP releases.  The criteria for and purpose of an RC release is different than that of a beta.  In the beta time frame, there can be new features added and major changes made.  We use betas to seek feedback and then make changes based on that feedback.  An RC release is the first one where we don't expect to be making major changes afterwards.

    James, beta has never (at least not for the past few decades that I've been paying attention) meant release candidate.  A beta release was always something that still expected a lot of change.  The change in betas recently is that with the internet they've become much more public.  Their purpose hasn't changed terribly much though.

    I'm not sure why the vitriol over what we decide to call our releases.  If we wanted to call them "fred" it shouldn't matter.

  6. The problem with words is that people use them as sponges to absorb meaning.  As words change meaning over time, cognitive dissonance is unfortunate but inevitable.

    "Words mean things"

    -- Apocryphal

    "When *I* use a word," Humpty Dumpty said ... "it means just what I choose it to mean -- neither more nor less."

    -- Lewis Carrol, /Alice through the Looking Glass/

    "What's in a name? That which we call a rose / By any other name would smell as sweet."

    -- Shakespeare

  7. Grant the corruption of the word "beta" has been under way for a very long time (which is why I included the brief history of the word), but it really did orginally mean essentially "release candidate".  It dates back to the IBM mainframe, pre-shrink wrapped software days, where the total distribution of an application was generally under 100 copies, and frequently under 10.  There were no user-friendly GUIs nor variations in the hardware platform, nor, for the most part, multiple-function applications. "Something that still expected a lot of change" in those days was "Something that just didn't work" and would not have been released to anyone-- The tester would have consider it just a waste of his time.

  8. Thanks for the history lesson James.  That's why I limited my response to the past few decades.  I didn't realize the word meant something different at IBM but I figured if it did have a different meaning, it would be back then.  Thanks for letting me know that it was different way back when.  I have a bit of an interest in the history of computing so it's always cool to learn something like this.

  9. "In the beta time frame, there can be new features added and major changes made.  We use betas to seek feedback and then make changes based on that feedback."

    Then why was Beta 2 considered feature complete and what would be the point of releasing it as Beta 2 and not as RC0?


  10. (Please note I'm not speaking officially here.  These are just my observations.)

    Good question Supercat.  Beta 2 was considered feature complete but we knew that feedback from it would prompt substantive changes.  Going into the beta, we expected to be making big changes.  Going into the RC, we don't.  Additionally, a beta might be released with some known bad bugs as long as they aren't in mainstream scenarios.  For the RC, we hope to have all the really big stuff fixed.

  11. "In the beta time frame, there can be new features added and major changes made.  We use betas to seek feedback and then make changes based on that feedback."

    Ummmm....isn't that what most of the rest of the software development world calls "alpha"? "new features" and "major changes" are things that tend to reduce stability somewhat, and "alpha" builds are not necessarily expected to be stable. OTOH, "beta" releases are generally thought of as being of increasing stability/quality, and therefore not very open to "new features" and "major changes".

  12. PingBack from

  13. Adam: typically, "alpha release" is an oxymoron; alpha (as I understand it) is only used for internal builds.

    I agree that alpha builds are not expected to be stable in any sense of the word, but I think you're doubly-interpreting two meanings of "stable" in your last sentence:

    stable(1): doesn't crash

    stable(2): features don't change

    I agree that betas should show a certain level of stable(1).  But I disagree with your assertion that once you've released a beta, you can't make major changes to the product.

  14. Windows Vista--the product I've been working on for much of the last 5 years--has finally shipped . Hopefully