Service packs, feature packs and releases – how they should work

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

The various Microsoft product groups issue service packs, feature packs and releases. This is all very well, but they mean different things to different people and are confusing. Then, last Friday, Paul Thurrott reported in the Windows IT Pro magazine network WinInfo Daily Update that Virtual Server 2005 SP1 will now become Virtual Server 2005 release 2 (R2). This might sound like a trivial name change but what it means for legal users of Virtual Server 2005 (a basically good product, but with a few fairly significant bugs), they will need to purchase R2, rather than install a free service pack.

If Microsoft follows this path they are going the way of Apple, who issue point version upgrades to their OS X operating system and have the audacity to charge existing users for a full product (there is no upgrade available).

In my opinion:

  • Service packs should fix bugs (security or otherwise) and that critical patches should be released in advance of a rolled-up, regression tested, service pack. Ideally service packs should also have a predictable timescale (e.g. 6 months after product release then every 12 months from then on until the product reaches end of life).
  • Feature packs should offer new features for an established product. I don’t believe that there should have been any additional features included with Windows XP SP2 (e.g. the Windows Firewall) – instead SP2 should have been a set of bug fixes (alleviating some of the deployment issues associated with new technology) and additionally Microsoft should have offered a free feature pack for Windows XP which provided the extra security features. In this way, users can stay at the latest supported product release (service pack level) but choose which feature packs to add. Security features and other important updates should be free of charge. Others which enhance a product might carry a small charge.
  • Mid-life releases (e.g. Windows Server 2003 R2) are all very well as a marketing mechanism for rolling the latest service packs into a product for new users, but should not preclude existing users from gaining from the latest service pack/feature pack updates. If a product really warrants a new licence, then it should carry a new (major) version number!

Following this model, Virtual Server 2005 R2 should really be a service pack and there should be an additional feature pack for the new features which Microsoft plans to ship (of which there are precious few details at present). As for supporting Linux as a guest operating system – it either works or it doesn’t – Microsoft needs to make up it’s mind as to whether it is a supported guest or not (if they are smart they will say “yes” – that way users can have a virtual Linux guest running on a Windows host if they need the best of both worlds, with Microsoft still gaining licence revenues for the host operating system and the virtualisation software).

5 thoughts on “Service packs, feature packs and releases – how they should work

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.