So, what's a CTP anyway?

Recently, we announced that instead of releasing SQL Server 2005 Beta 3, we would move to a model of releasing multiple CTPs (Community Technology Preview) up until the final release of the product later this year. But what exactly does this mean? How is a CTP different than a beta?

Historically, beta releases have been the mechanism that external customers give us feedback about features and report bugs in the product. A product release might have an alpha and one or two betas (but no gammas or deltas, wonder why?) before RTM (Release to Manufacturing). Betas are really big productions that require CDs to be duplicated and mailed out to all the participants in the beta program. It also required a large amount of coordination as customers had to have resources ready to test the betas. Since betas were few and far between, it also might be a long time for them to see when reported issues had been resolved. The goal of CTPs is to shorten this feedback cycle.

To understand how the CTP works, you need an a basic understanding of the Microsoft development process. Most product teams are on a daily build schedule, that is, a new version of the product is created every day. In the middle of the night, a copy of the latest source is pulled down to a farm of build machines where the binaries are built and assembled into setup. With a large product team like SQL Server there could be hundreds of small changes between builds. This means while daily builds are generally usable, they are sometimes "less than perfect". It is well known that Microsoft encourages everyone to "eat their dogfood" but installing a bad build can result in lots of lost productibity. So, in an effort to provide a higher quality build for people to use in their day-to-day work, the IDW process was born.

While no one seems to know exactly what "IDW" stands for, it is an interim build that meets a set of criteria for release to a larger audience outside of the product testers. The frequency of IDWs depends on the team and varies from weekly IDWs to bi-monthly. While they are full interim builds of the product, until recently, IDWs rarely went outside of Microsoft, and if they did, only to a select set of customers. But the arrival of widespread broadband connectivity has made it easier to deliver large product builds to customers and electronic forums have made it easier to file and track bugs and suggestions. Visual Studio 2005 had already moved to a model where they were delivering interim builds to customers via MSDN, so after Beta 2, the SQL team adapted our IDW process for external delivery and began releasing CTPs.

The CTP process has been great and we've been able to get newer builds in peoples hands quicker. Customers can grab the latest build and at most, it will be a few months old. It might mean more churn for customers that want to try out every build but they can also get faster feedback on how they are impacting the product.