The cost of frequent bits updates

Sharing Whidbey interim releases more frequently  (Mark Cliggett, via JayBaz, via Scoble) with our developer community is a great step for MS, I think. I love to see the Whidbey team being more open and engaged with the community

 

On the other hand, there are downsides to having frequent releases:

1) Quality of each build is less determinate, as Mark points out in his blog entry. While each new build will have features that didn’t work before, it might also break things that previously worked well. If you have 50 developers checking in 3 fixes a day, even a low low regression rate of 1% leads to 7 or 8 new issues each week

2) Less community consistency – the odds that you have the same build as the other folks on the newsgroup, or the guy posting sample code on his blog, start to go down. This has the potential to really harm the community I think, if we’re not able to help one another out with issues or post samples that work for everyone.

3) Cost of wipe-and-reinstall. Interim builds likely won’t support any sort of upgrade, or patching (as has already been requested in some blog comments). So you’ll have to download the whole thing, uninstall the old build (assuming there aren’t any bugs in the uninstaller that instead require you to reformat and start from scratch), install the new build, and then manually fix up any code that no longer works.

 

I’ll be interested to read the general reaction to the more frequent releases.

 

There has been some chatter about whether releases should be made available to the general public, vs. only as a download for MSDN subscribers. I don’t have any insight on what path the Whidbey team might chose, but for me, the issue is not one of elitism, as some commenters have suggested. I think it’s more about managing expectations.

 

Putting up a new build for a limited audience of committed MS developers (MSDN) sends the message that this build is not ready for prime time, and it’s stability is low enough that the casual/hobby programmer won’t get much benefit out of it. Putting up a build on ms.com or msdn.com where the whole world can download sends a stronger signal that this is a build many people could benefit from. At least, that’s how I’ve heard it discussed internally.

 

Of course any build on MSDN will get broadly leaked anyhow, and pirated onto CDs in Singapore or what have you. That’s why the point isn’t about access, it does seem like anybody who wants the bits will be able to get them regardless.