Jason Sacks's Windows SDK blog

Now that we've reached the mythical Zero Bug Bounce for the Windows SDK, we're finally ready to start thinking about our next few releases. I mentioned when I last posted to this blog, over a month ago (shame on me!) that the SDK team doesn't get to take a deep breath, drink mai tais on a beach in Hawaii and relax before we release our next version. Instead, we're sitting here in rain-drenched Redmond, thinking about what approach we want to take for our next few releases.

We have a couple of minor releases coming up, but the one we're thinking about the most is our work in Visual Studio "Orcas." The Windows SDK is essentially an extension to VS "Orcas", providing tools, headers, libraries, samples, docs and other content to maximize Visual Studio development targeting the Windows platform. If you look at that sentence and have trouble understanding how a VS developer wouldn't care about the platform, you can understand why this work is so complicated. Really most of our discussions are around how we integrate with VS's work. For instance, as a setup PM, I'm thinking about different scenarios. The scenarios have a broad range, from having the SDK be installed silently to having the SDK be a visible and customizable component in the VS setup.

These decisions are, of course, being made by Microsoft folks higher up the food chain than I am. But the issues exposed cascade down to decisions that I, and my fellow PMs, have to think about. If we're installed silently, for instance, how do we expose our features in the VS custom selection tree? Because our build system is different from VS's, what are the pitfalls in integration? Given that it's a certainty we'll deliver a web download for VS "Orcas" RTM, how much of that setup is reusable?

As I wrestle with these questions, I'll post about them. And I'm always anxious for your feedback on what you think the best decisions are for the SDK.