Release Management
Cuando son conocidos los requerimientos, dependencias y plazos, se comienza la construcción de la nueva entrega. El primer paso es el diseño de la nueva entrega. Se puede hacer usando técnicas de desarrollo de software, por ejemplo UML. El diseño es convertido en código fuente de algún lenguaje de programación (por ejemplo C). Se da a conocer a los desarrolladores la fecha de término para cambios (congelar el repositorio). Las piezas de código, clases, archivos de configuración, etc son entonces traídas desde el repositorio mediante un checkout, compiladas, enlazadas y finalmente armadas en un solo programa, un built. Se debe colocar una marca (tag) en el repositorio sobre la versión que fue traída, para posteriormente conocer el estado de avance de la versión usada por el usuario.
Proyecto Debian
Cuando la "versión de pruebas" llega a un nivel aceptable de fallos, entonces se ""congela"", lo que significa que ya no se aceptan nuevos paquetes desde la versión inestable. A continuación se trabaja para pulir el mayor número de bugs posibles, para así liberar la versión estable. Ese periodo puede durar varios meses debido a que no se fija una fecha de lanzamiento. Debian no será liberada como estable en tanto sus desarrolladores no consideren que lo es. Esa estabilidad se mide basándose en el registro de errores de software. Cuando se alcanza un nivel aceptable se le asigna un número de versión, acordado previamente, y se libera como ""versión estable"" (solo las versiones estables cuentan con número de versión). La anterior versión estable es clasificada como ""old-stable"", recibiendo soporte durante un período determinado (generalmente un año), y posteriormente será abandonada.