#BackToBasics: Definitions of SQL Server release acronyms
Some content updated April 2nd, 2018
Several months back, you may recall that I committed to meeting Tim Ford's challenge to write an entry-level post at the beginning of each month of 2016.
I sometimes take for granted that everyone reading my posts must know what CU, QFE, and GDR stand for and, ultimately, what they mean. (In fairness, Microsoft and others do the same thing.) So I thought I would throw together a quick glossary page to help explain the ones that I see used most often.
|Acronym||What does it stand for?||What does it mean?|
|COD||Critical On-Demand||This is a fix for an issue that is deemed "critical" because of the severity of the issue, the number of customers it affects, or the lack of a feasible workaround (usually a combination of two or all three). The fix is released out-of-band from the usual Cumulative Update / Service Pack release cycle, and then rolled into the next Cumulative Update (or, depending on timing, the one after that). A COD can sometimes contain more than one QFE (defined below).|
|CTP||Community Technical Preview||This is a build of the "next" version of SQL Server (or sometimes a Service Pack) that can be used for testing new features and reporting bugs. With few exceptions, CTPs cannot be used in a production scenario, and they are usually limited to Express / Evaluation Editions.|
|CU||Cumulative Update||This is a roll-up of multiple fixes that occurs between Service Packs, usually on a 60-day cycle (though that is subject to change). It used to require an e-mail and password to download and extract the files, because they were "less tested" than service packs, but this is no longer the case. Functionality can also be added in Cumulative Updates (previously, this would only happen in Service Packs, and before that, only in major releases).
You should feel comfortable applying Cumulative Updates as quickly as your regression and other test processes allow. Kendra Little just published a fantastic blog post about this, and I highly recommend giving it a read right now (or bookmarking it for later). I feel pretty strongly about this because just about every CU has engine-related fixes that affect stability, performance, and sometimes address corruption / incorrect results.
Note that these updates are cumulative. I see this asked all the time: "To apply CU2, do I need to apply CU1 first?" NO.
Also note that Cumulative Updates are only for the branch where they're released. You can't apply an SP1 CU to RTM or SP2; only to SP1.
|GA||General Availability||For the traditional SQL Server product, this usually means that you can download the ISO from the usual sources (MSDN downloads, the TechNet Evaluation Center, or your volume licensing servers).
For Azure SQL Database, this usually means that you can go and turn on the functionality without first agreeing to a waiver about preview functionality.
|GDR||General Distribution Release||A GDR fix contains issues that are security-related and/or have a wide impact, and are released without any other critical updates that have been released for the specific branch. These are typically used by customers who need the fixes they contain, but don't have the resources to test all of the other fixes that come with Cumulative Updates.|
|QFE||Quick-Fix Engineering||This is a potentially less-tested fix (also sometimes called a hotfix) that gets distributed to a small number of customers for a very specific issue, through a COD or CU. (In the Windows world, this is called an LDR - Limited Distribution Release - but that nomenclature has not caught on in the SQL Server team.)
At my previous job, we received a private QFE for a SQL Server 2005 issue with temporary tables for destruction. That fix eventually made it into a Service Pack (though I can't recall if it was an officially documented issue).
|RC||Release Candidate||This is a build that is almost ready for final release (RTM / GA). Usually it is feature complete, with the only remaining work comprised of minor bug fixes and fit & finish. However, this isn't always strictly the case, as a few behavior changes were introduced in RCs for SQL Server 2016.|
|RDP||Rapid Deployment Program||No, this has nothing to do with remote desktop; it refers to a set of "early adopter" customers, usually used to help market the launch of a new version or feature. These are almost always a subset of TAP, and are almost always running the new version in production months before it is available to the public. James Serra goes into more detail here.|
|RTM||Released to Manufacturing||This means that the release is ready. Back when Microsoft shipped software on CDs and later DVDs, this represented the point in time when the discs could be printed. Not to be confused with launch (which is a marketing thing only) or General Availability (which means you can actually get the code). The delay between RTM and GA is much shorter now that software is generally distributed online instead of on physical media.|
|TAP||Technology Adoption Program||This describes a set of customers that help Microsoft shape and test specific features for a new release (or help shape and test new features individually). Most recently, we were part of the TAP program for SQL Server 2016, but we have been involved in several others as well.|
|SP||Service Pack||A Service Pack is, now, essentially a Cumulative Update with slightly different labeling. It is a roll-up of updates (including bug fixes and security updates) and sometimes contains new features.
Like Cumulative Updates, Service Packs are cumulative. If you are applying SP3, you do not need to first deploy SP1 and SP2.
As of SQL Server 2017, there will be no more Service Packs, just Cumulative Updates. Generally, for the first year after release, you should expect these about once a month. Then every quarter for the next four years, when the product hits the end of mainstream support.
Unfortunately I have been unable to find a single, official resource that describes all of these terms in one place, but you can see much of what I've said corroborated in the following articles:
Aaron (@AaronBertrand) is a Product Manager at SentryOne, with industry experience dating back to Classic ASP and SQL Server 6.5. He is editor-in-chief of the performance-related blog, SQLPerformance.com, and serves as a community moderator for the Database Administrators Stack Exchange. Aaron's blog focuses on T-SQL bad habits and best practices, as well as coverage of updates and new features in Plan Explorer, SentryOne, and SQL Server.