But now let’s talk about how we’re really trying to approach it. Today is 3/9 and we’ve not set a date for the next build. I have a build in hand that we produced on Friday. It was validated by our test automation, and will go out through our internal rings and get installed and used by thousands of people at Microsoft. It is the freshest code with all newest features and fixes. If it passes all of our evaluation criteria it could be in your hands late this week or early next week. That means that we could feasibly get multiple builds out in March rather than just one, and they’d have more up to date code than if we did it the other way. Yes, I know, that is pretty big talk considering it has been more than 40 days since our last build; and here I am talking about multiple builds per month. I’m sharing our aspirations and what we’re building towards, and we want to be working in that new way vs. the way we used to do it. Not having the constraint of a fixed public date for each build helps us get there faster. Here’s a real example though: We had a debate internally about whether we should announce a date for 9926 – the build we shipped the day after our 1/21 Windows 10 event. The choices we had:
Now this is good news!!