En el argot interno de Microsoft, un build declarado como 'escrow' designa la compilación que se enviará a clientes si cumple los objetivos de calidad y fiabilidad fijados. Aunque a primera vista parece equivalente al concepto estándar de release candidate, el equipo de Windows NT evitó ese término porque ya tenía otro significado dentro del proceso de lanzamiento.
El texto repasa la evolución del nombrado de las versiones previas a un lanzamiento. En los primeros tiempos de Windows existían builds internos compartidos con socios, bautizados con el número de compilación o el hito del proyecto, seguidos de betas dirigidas a un público más amplio, incluyendo empresas que evaluaban compatibilidad. Los release candidates llegaron después como versiones prácticamente definitivas: si todo iba bien, esa era la build que se enviaba a fábrica. Windows 95 necesitó seis release candidates antes de выпуска.
El problema surgió con Windows NT: muchas empresas y fabricantes de software ignoraban los betas por considerarlos poco fiables, y solo comenzaban a probar sus aplicaciones cuando aparecía el primer release candidate. Las correcciones que pedían resultaban a menudo imposibles de aplicar porque la documentación, las traducciones y los manuales ya estaban maquetados. El autor recuerda una reunión durante Windows XP en la que cambiar 20 KB de un archivo de ayuda habría costado cientos de miles de dólares solo en retraducción.
Para romper esa dinámica, el equipo de NT recurrió a la 'inflación de notas': las últimas betas pasaron a llamarse release candidates, y los antiguos release candidates se rebautizaron como builds en escrow. El término transmite la idea de que el proceso ha terminado y solo queda firmar; ya no se introduce ningún cambio salvo emergencia real.