Frequency and predictability of Windows 10 builds for Windows Insiders
Micrsoft’s Gabe Aul, in a post on the Windows blog today, offered a good degree of transparency on how the process works internally and how the team decides when and what to release.
Let’s play that out hypothetically for the next build coming out. Today is 3/9 and we want to ensure we get a build out in March. If we communicated a target date, to be sure we could meet our commitment we’d likely pick a date like 3/26. It gives us time to stabilize and it’s on a Thursday (we usually like to avoid Mondays and Fridays.) Between now and then we’d still be getting new feature payloads, but we’d fork to a stabilization branch somewhere around 3/17 or so and only take selective changes. It’s easier to stabilize without a lot of additional new code, so we’d cherry pick key fixes. On 3/23 we’d have a candidate build, and we’d flight that out broadly within MS to make sure we could find any gotchas and meet our date with confidence. Hey, that doesn’t sound too bad does it? Except in the ‘worst case scenario’ where we miss the date and people are let down, it means a predictable date about once per month with kind of up to date code.
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:
1. Set 1/23 as the announced date, knowing it would have been a build produced weeks before without many of the features we demoed.
2. Set 2/15 as the announced date, giving ourselves the flexibility to have a good build in escrow.
3. Don’t announce a date, use the ring promotion process, and go when ready.
We went with option 3 and it paid off. We got a much fresher build out, with more features and fixes, and we were able to ship on 1/23 as we’d aspired.
More @ Windows Blog
