What goes into a Service Pack?

With the VS 2003 Service Pack 1 released and the VS 2005 Service Pack 1 release imminent, it’s a good time to talk about what Visual C++ Service Packs contain and the rationale behind this.

 

The primary purpose of a Service Pack is to improve the stability of the product over what was initially shipped. I know sometimes it’s hard to believe, but Visual C++ does ship with bugs!  Most of these bugs can be worked around or are unnoticed. Some bugs, however, do block progress.

 

It’s the bugs that block progress that we focus on for Service Packs. We also roll in hotfixes made since the last Service Pack. Hotfixes are bug fixes that we do for customers who are so blocked that they can’t wait for even a Service Pack.  Examples of issues we look for are around security, accessibility, crashes, hangs, data loss, corruption, and resource leaks.  The critical factor in deciding to investigate these issues is whether they present situations that block customer progress.

 

After investigation, we discover a number of the possible set of issues don’t block progress after all.  And we invariably find issues that would require significant changes to the Visual C++ code base to fix.  Examples of significant changes may include small changes to core areas of the product or architectural changes.  Such issues don’t usually make the cut to get into the Service Pack.  Remember the goal is to improve stability: We don’t want to add more blocking issues as a side effect of fixing a bug.

 

This is also a key reason why we rarely add feature enhancements to a product via a Service Pack.  We don’t want to add more blocking issues.

 

Service Pack beta periods are usually pretty short. This is because there is such a high bar for bug fixes that there isn’t expected product instability.  It also allows us to get fixes distributed more broadly more quickly if we shorten the development and pre-release periods.  This rapid release approach also re-enforces the high bar for fixing bugs.

 

VS 2003 Service Pack 1 is just such a Service Pack as was VS 2002 SP1.  VS 2005 SP1 is a little different in some respects – mostly in the number of bug fixes. (see the September 27th blog for our beta 1 announcement).  Normally, we wait for someone to tell us that they are significantly blocked before we fix a bug for a Service Pack. With VS 2005, we spent some considerable time after VS 2005 shipped fixing issues that were reported via the Product Feedback Center, via product support, etc.

 

Because VS 2005 contains so many more fixes than we normally put into a Service Pack, we would welcome more developers than normal installing the beta and trying it out. This Service Pack should have broader appeal because there are so many fixes in so many areas of the product. So if you haven’t tried out the VS 2005 SP1 beta yet, please give it a whirl. You can sign up and download the Beta by accessing the Microsoft Connect site at https://connect.microsoft.com/visualstudio.

 

 

Shaun MillerQA Lead
Visual C++ Release/IDE