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.
Sistema de gestión de paquetes
Cuando un usuario interactúa con el gestor de paquetes para realizar una actualización, este suele mostrar una lista de las tareas a realizar (normalmente la lista de paquetes a actualizar y, posiblemente, también los números de versión) y también es probable que permita realizar una actualización completa o bien seleccionar los paquetes que se desea actualizar. Algunos gestores de paquetes permiten indicar los paquetes que no se desea actualizar nunca o solamente cuando estos corrigen errores importantes en la versión anterior. A este proceso se lo suele denominar "version pinning". Por ejemplo, yum permite esto mediante la sintaxis "exclude=openoffice*", pacman con "IgnorePkg=openoffice" (en ambos casos para evitar la actualización de OpenOffice), mientras que las herramientas de Debian poseen una sintaxis más compleja y potente.