So one of the biggest questions that has been going through the mind of many beta testers, and the community alike is simple.  Will there be any interim builds of Windows 7 between beta and RC?  The simple answer to that question is no, but in reality, the reasoning behind it is much more complicated than a simple one word answer.

Many people are familiar with the fact that during the Vista beta there were regular interim builds.  These builds usually came once a month, sometimes the span was longer depending on various factors.  Of course after the conclusion of the Vista beta process, Jim Allchin retired from his post as Windows Chief and the responsibility of all things Windows was then given to Steven Sinofsky, who was previously the man that oversaw Office.  Steven was brought over because of his ability to keep projects on a very rigid schedule and ensure that the end result was a very high quality product.  But one of his policies over in the Office arena was centered around the beta program; there was never any interim builds of Office, it was milestones only.  This engineering paradigm has been brought over to Windows.  Techbeta testers will NOT be receiving interim builds of Windows 7.  They have received beta in early January, and they will receive RC bits in April, at which time they will be able to evaluate that build and see if their bugs and issues have been resolved from the beta build.

Now, I’m sure some of you are asking what the reasoning behind this milestone only policy is?  I was actually asking myself the same question, so in order to get the proper answer I went to the man himself, I asked Steven Sinofsky.  I asked him about the possibility of releasing interim builds for Windows 7 to the techbeta testers for the purpose of using such builds as a tool to verify bug fixes and ensure that things were moving in the right direction.  I honestly was not expecting a reply as I understand that Steven is undoubtedly a very busy man.  But when I checked my inbox a few hours later, not only did he respond, but he did a very good job explaining his position and why the interim builds were not a good option for this release cycle.

One of the things Steven did to streamline the windows development process was to eliminate the idw validation process for builds in between milestones.  What I mean by this is that every build that was given to techbeta or any broad external group during windows betas was not a “trunk” winmain build, but rather a build that was run through verification tests, recompiled a bunch of times and then pumped out to the testers.  So to illustrate this I will show you an example of a build that went through such verification testing:

5231.0.winmain.050912-2020 – As you can see, this is a “trunk” winmain build as defined by the .0 and the plain winmain designation in the build tag.  This build was selected to go through verification tests and be given to testers.

5231.2.winmain_idx03.051004-2120 – This is the build that was given to testers.  As you can see, it was recompiled a number of times between September 12th and October 4th and went through many verification tests.  It was also refined in a different lab, hence the addition of the _idx03 suffix to winmain.  This build was then given to testers after verification was complete.

As you can see by the above example, Microsoft spent roughly 3 weeks to verify build 5231 in order to release it to beta testers, time that is now being saved since they no longer have to do this every month.  Another example (an even more ridiculous one) of this verification process is the following:

5308.17.winmain_idx01.060217-2200 – WOW, .17, so it was re-compiled???  Yeah, pretty much.  Like I said, they spent a LOT of time and resources during the Vista beta to prepare these interim builds for release to testers.

Anyway, the point of the above examples is to clearly illustrate the point that Steven made to me when explaining the reasoning for the decision.  The creation of interim builds creates more activity internally then it does real progress towards the end product.  He doesn’t want the teams pre-occupied with prepping builds when they can be focusing full efforts on working towards the next engineering milestone.

So this brings me to the next question that I posed to Steven.  I told him that given the fact that OEM’s, IHV’s, Windows Vendors, and TAP Program members all get frequent trunk winmain builds, why not give techbeta one of those builds once a month and explicitly state that such builds have not been quality checked and may cause your machine to explode (no not really explode, but still)?  He responded that Microsoft did not want to do that because it would create a bad image for the product if the build was bad, and it would also expose issues that beta testers may have never seen otherwise.  He explained that if a build were to fail, on install or in another way, people would not necessarily like to go backwards, seeing as it would mean another format and reinstall of the OS and all software.  I have to say I agree with him in a way, the testers would go insane if there was a build drop that didn’t work on their machine and caused major issues, but the inner geek in me know that I would be willing to take the risk.  I have tried several trunk winmain builds and I have not had any major issues with any of them, up to and including 7022, but that doesn’t mean that others won’t.  I do understand Microsoft’s position on the issue, and if it helps streamline windows development and help bring us a better product in the end, then so be it.  I look forward to seeing what Windows 7 brings.

I hope this answered your questions, but I’m curious to see what you all have to say about this, so please leave your questions or comments in the forums and I’ll be happy to answer any that I can.

Source: Me

Discuss: GeekSmack Forums