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.