Dan Jones, Microsoft’s SQL Server Manageability PPM, recently posted the proposed list of SQL Server Code Name Denali upgrade paths and operating systems. His team is soliciting feedback on their selections, as well as on the way the installer should deal with unsupported systems.
The proposed list of supported OSes is currently:
- Windows Vista SP2 or later
- Windows Server 2008 SP2 or later
- Windows Server 2008 R2 SP1 or later
- Windows 7 SP1 or later
The list of SQL Server versions with supported upgrades is:
- SQL Server 2005 SP4 or later
- SQL Server 2008 SP2 or later
- SQL Server 2008 R2 SP1 or later
If the system does not meet these requirements, the installation will fail.
Initial reactions on Jones’s blog are mostly favorable, and generally agree with the decision not to support older operating systems like Windows 2003 and XP. However, a few developers note that while they agree with the idea of only running SQL Denali on a current server operating system, they’re still stuck using XP on their development machines. Aaron Bertrand responds to this on his blog:
My argument here is that very few such companies are going to sit on XP on the desktop for 10+ years, but be running bleeding edge software in their data centers. How many of these companies won't let their DBAs run anything newer than XP, but will be an early adopter for Denali?
Allan Hirt points out another potential issue: by supporting Windows Server 2008 (not R2), Microsoft is obligating itself to provide a 32-bit version of SQL Denali.
It's time to move on. 32-bit has been a great platform, but let's retire it with dignity. This does not mean that Microsoft shouldn't support 32-bit on the desktop... I'm purely talking about deploying it in a production capacity.There's another big reason I would recommend this: make the testing matrix smaller. Removing 32-bit as a server platform allows MS to have better testing coverage for everything else.
The proposed upgrade path list is significant because this is the first time Microsoft has required a specific server pack, rather than including all the required updates with the SQL Server installer package. That could add significant extra time to the upgrade process, since administrators would have to install and test service packs before proceeding.
Microsoft is still accepting feedback on their proposals. Those who wish to contribute can do so via SQL Server Connect or a comment on Jones's blog.