Skipping SQL Server Versions

I wanted to follow up on a few topics related to last week's editorial in which I wondered whether customers might leapfrog from SQL Server 2000 straight to SQL Server 2008 (code-named Katmai). You can read last week's editorial "Leapfrogging to Katmai" and peruse the reader responses that have come in so far.

Only time will tell, but the initial reader reaction certainly suggests that many customers will leapfrog to SQL Server 2008. However, I’d like to refine my original thesis to acknowledge that customers who haven't yet migrated to SQL Server 2005 will have a high rate of leapfrogging to SQL Server 2008 while customers who have migrated to SQL Server 2005 are already contemplating skipping SQL Server 2008. We might end up with a mid- to long-term scenario in which the SQL Server community will be split across several different SQL Server releases, with a large percentage of users ultimately skipping entire versions. Having the SQL Server community fragmented across multiple versions isn’t necessarily a bad thing, but it will be interesting to see if Microsoft stays committed to rolling out a major release roughly every two to three years, as is the company's goal today.

It was easy to pick on Microsoft when the gap between SQL Server 2000 and SQL Server 2005 was as long as it was. Likewise, it’s easy to pick on Microsoft when the company releases major SQL Server versions on a timeline that makes it difficult for customers to see the monetary value in keeping up with each release. I suppose it’s not fair to pick on Microsoft simultaneously for both problems, but heck, coming up with good ideas for this commentary every week can be hard, so all’s fair in love and editorial writing.

Still, I wonder if there isn’t a nice middle ground where Microsoft can increase its investment in the feature pack model that the company has been pursuing for SQL Server and numerous other Microsoft products. Feature packs aren’t major releases of the product, but they often add substantial functionality in key areas. A major release of the product is often necessary if core changes are being made to the data engine or other key parts of the product's architecture. However, sometimes the "killer" feature you’re waiting for isn’t a core architectural change and can be released in a feature pack or interim minor release on a cycle much faster than every two or three years. Leapfrogging major releases might be more palatable to some customers if they can get new goodies from a feature pack every now and then. My sense is that Microsoft could be successful with this approach if the company considered releasing its tools on a more frequent update cycle. I wouldn’t mind seeing formal release cycles of administration and development toolsets for SQL Server being every year rather than every two or three years. What do you think?