In case you haven't yet heard, Microsoft SQL Server 2008 service pack 1 was released on April 7.  This milestone is especially significant for those of you who could not previously deploy the latest SQL Server release because your organization has a "not before the first service pack" policy.  I want to go on record as one who believes that such a policy is flawed and has needlessly delayed many organizations from using the new SQL Server 2008 features.

There is nothing magical about the first service pack compared to the initial RTM release with regards to production readiness.  SQL Server releases nowadays are scheduled based quality rather than just hitting a date.  Buggy features will be dropped from a release rather than included and in need of a service pack.  I'm not saying that every SQL Server release is flawless but the number of serious bugs (e.g. corruption or wrong results) are few, thanks to internal testing by Microsoft as well as those in the community that kick the tires with the pre-release CTP bits.

It's understandable that those who are risk-adverse might wait until after the first service pack with the belief that other adopters may have smoothed out the bumps in the road a bit.  I can see how postponing installation in this way might mitigate some of the risk but SP1 is a completely arbitrary milestone that is a hold-over from before SQL 7 was released over a decade ago.  I think a better approach is to adopt new releases based on quality as determined in one's own environment.  Whether the target is a new SQL Server installation or an upgrade of an existing instance, one still needs to perform testing before installing any new version, service pack or patch in production.  It is those test results that should determine production readiness, not the results of SELECT SERVERPROPERTY('ProductLevel').