As a product is nearing release, the release management selects a build and declares it to be the escrow build. The metaphor is that this build has been placed into the hands of an imaginary third party for eventual release to customers provided certain requirements are met.
Those requirements are that the product survive a period of concerted testing and self-host usage to build confidence that it meets its quality and reliability targets. The Developer Division Release Team blog unhelpfully described escrow as “the phase before the completion of the RTM milestone where the product goes through a period of bake time.” I say unhelpfully because it defines one Microspeak term (escrow) in terms of another Microspeak term (bake time). Some time ago, I defined the Microspeak term bake as “(of a code change) to build confidence by observing its behavior over a period of time.”
Putting this all together, a more complete definition of escrow would be “the phase before the completion of the RTM milestone where the product accepts no changes while its behavior is closely observed to ensure that it meets release criteria.”
When a problem is found, the release team has to assess whether this problem is significant enough to require a product change. This assessment is a balance of many factors: How often does it occur? Does it affect one category of user more than another? How severe are the consequences? How easily can it be worked around? These criteria are typically¹ formalized by a bug bar.
If a severe enough bug is discovered, then an escrow reset is declared, and the bug fix is accepted,² a new build is produced, the new build is declared the new escrow build, and the cycle repeats.
Eventually, the product makes it through the escrow period without any escrow reset events, and the escrow build is released to manufacturing.
¹ Though not always, apparently.
² Plus any bug fixes that were granted “opportunistic” status by the release management team.
Wow, I had forgotten about the regular “Pre-emptive Igor Levicki comment”, what a flashback!
Whew, really? When you mix your metaphors that hard you often produce an overly tough cake.
I discovered that bug bar does not work; and you’re essentially always better off merging all fixes that merge cleanly into the release branch into the release branch right up until mastering the release.
But then again I don’t know what ten thousand developers is like.
Probably more a matter of having ten million soon-to-be-users than ten thousand devs. How confident are you that a fix won’t accidentally introduce a new bug, hitting an edge case you didn’t even realize was there much less write tests for? The bug bar would then be a combination of how severe a bug is fixed contrasted against the worst-case new bug it could plausibly introduce.
You do not need thousands of developers for this to make sense. Even if you work alone, you better set a bug bar when you are working on an RC, escrow build or whatever you call it. Every change, including bug fixes, comes with a risk of regressions. And this is specially critical in the last stages: even a minor bug fix risks introducing itself a bigger bug. The bug bar allows you to better evaluate the risks of applying the fix versus the effects of letting the bug go into production.
“Bug bar” is the ultimate corporate euphemism for “How many bugs can we get away with shipping?”
Preemptive Yuhong Bao/Igor comment: “Windows 11 escrow time is close to negative infinity”
Hey I have been summoned!
No, Windows 11 doesn’t even have an escrow build.
Given the “quality” of the last year worth of KBs released the Windows source code has apparently turned into a collection of bugs which sometimes also function as an approximation of an operating system.