With various news reports that a “Release Candidate” or RC of Windows 8 is due in May or June it is useful to reflect on how that term has been corrupted over the years, particularly by Microsoft’s Windows team.
Once upon a time you did a series (one to three) of beta releases, followed by a series of later builds that were for internal testing. Some of those later builds were also given to close partners (internal and external to Microsoft) to test as well. At some point you were doing builds that only contained a handful of bug fixes, and when you did a build that contained all the planned bug fixes it became a “potential RC”. Only if internal testing revealed no additional bugs needing to be fixed, and thus the build appeared ready for release, would you declare it the Release Candidate. In other words, you only called something a Release Candidate if it was something you thought actually had the potential to be released. Often when you produced the RC there were still a few problems that needed investigation, triage, and occasionally a fix, plus you’d hand out the RC to your partners (to test and even put into production for a few days) and that would produce a few more problems to investigate and triage, so in reality there would be a small number of RC builds before you actually had something to Release to Manufacturing (RTM). But this was a process that would take a week or two, not months.
Somewhere along the line the Windows team started treating the notion of Release Candidate differently. RC now marks the point in which all functional and user experience changes are complete and they enter a bug fix only mode. The bar for making bug fixes goes up, but doesn’t seem to be limited to Priority 1/Severity 1 bugs (e.g., data corruption or other problems so significant that you would pull the software back from manufacturing to fix them) as it was for the traditional definition for post-RC builds. Other products would have called this another beta, and saved the RC designation for a true potential release candidate.
So while I’m excited by the possibility that we’ll see a Windows 8 “RC” in May or June, it is apparently going to be a build with quite a number of user visible changes. And that means the Windows team will need at least several weeks of testing and bug fixing before they can produce a true candidate for release to manufacturing.
Hal's (Im)Perfect Vision 
Hal, while I agree there have been examples of where RC was “corrupted”, I actually think that in the case of big Windows what we are really seeing is a much larger scope and far more complexity. The timeline has stretched from days/weeks to months, not because the concept of “Release Candidate” has changed, but because the scope & complexity of the product is so huge that getting it to partners, letting them do their own regression testing, getting feedback, doing regression testing, dealing with show-stoppers simply takes longer.
The alternative is to NOT budget enough time and then either slip RTM (talk about a no longer valid term) or ship with poor quality.
It turns out that there are very, very, few remaining examples of software products where any of this still applies. More and more the model is one of either almost or complete continuous deployment. Us old-timers need to get over the concept of Alpha, Beta 1, Beta 2, RC1, RC2, RTM, SP1…
My point wasn’t to defend the old end-game system, but rather to stop using the term Release Candidate for what clearly isn’t something you are going to stamp as a production release build. But if you are going to use that term, applying it according to the classic definition actually fits better than ever with modern end-game techniques. In SQL Server we literally only applied the RC terminology to builds we thought had a good likeliness of being the RTM build, then RTM’d that build if we didn’t find any showstoppers within a few days. What Windows does with its “RC” we did by shipping “IDW”/”Super IDW” builds out (sometimes weekly) to close partners (EAP/TAP participants, ISVs, MS IT, product teams with dependencies, MVPs, etc.) on a regular basis, something that has now evolved into their Community Technical Preview (CTP) process (which drops the classic beta altogether). I guess the real issue here is that RC and RTM used to be milestones or states, and somehow they became things. They need to return to being states.
I would label what the Windows team does as a “Production Preview”, and given what they have been calling the builds they hand out publicly hopefully that is what they’ll call it. Anything but RC please 🙂
For other products/services I agree that the processes are even more dramatically different than the old days, largely because we have the opportunity to service them continuously. So the real differentiator becomes what you are willing to support (and make assurances around) for production use. So things are always in Preview or Production state and you can label them accordingly.
It would be nice to see Windows move to a more agile model, one which results in a new technologies coming to market faster. The current 2-3 year lag between releases is no longer competitive is a world where Apple and Google are updating annually or even multiple times per year. I realize many enterprises wouldn’t want an endlessly moving target, but perhaps MS could have two seeds: a always updated one and the set in stone one.
Bob,
I think MS did that with Service Packs for XP. For Vista, well I think Windows 7 was in a sense, Vista SP1.