Primero revisemos el caso particular de la distribución Experimental: este es un grupo de paquetes Debian que corresponde a software que está actualmente en desarrollo y no necesariamente completado, explicando su nombre. No todo pasa por este paso, algunos desarrolladores agregan paquetes aquí para recibir comentarios y sugerencias de usuarios más experimentados (y valientes).

De lo contrario, esta distribución generalmente alberga modificaciones importantes a paquetes base, cuya integración a Unstable con errores serios tendría repercusiones críticas. Es, por lo tanto, una distribución completamente aislada, sus paquetes nunca migran a otra versión (excepto intervención directa y expresa de su responsable o los ftpmaster). Además, no es autocontenida: sólo un subconjunto de los paquetes existentes están presentes en Experimental y generalmente no incluye el sistema base. Por lo tanto, esta distribución es más útil combinada con otra distribución autocontenida, como Unstable.

Volvamos al caso típico de un paquete. Su responsable crea un paquete inicial que compila para la versión Unstable y la ubica en el servidor ftp-master.debian.org. Este primer evento involucra una inspección y validación de parte de los ftpmaster. El software luego está disponible en la distribución Unstable, la «cresta de la ola» elegida por los usuarios que prefieren paquetes más actualizados en lugar de menos errores. Ellos descubren el programa y lo prueban.

Si encuentran errores, los reportan al encargado del paquete. Quien prepara versiones corregidas regularmente que vuelve a subir al servidor.

Cada paquete recién actualizado se actualiza en todas las réplicas de Debian del mundo en un plazo de seis horas. A continuación, los usuarios prueban las correcciones y buscan otros problemas derivados de las modificaciones. Pueden producirse entonces varias actualizaciones rápidamente. Durante estos momentos, los robots autocompiladores entran en acción. El mantenedor sube las fuentes de los paquetes (sin ningún paquete precompilado). Los autocompiladores toman el relevo y compilan automáticamente versiones para todas las arquitecturas compatibles. Algunas compilaciones pueden fallar; el responsable recibirá entonces un informe de error indicando el problema, que deberá corregirse en las siguientes versiones. Cuando el fallo es descubierto por un especialista en la arquitectura en cuestión, el informe de fallo puede venir acompañado de un parche listo para usar.

Luego, el paquete habrá madurado; compilado en todas las arquitecturas, y no tendrá modificaciones recientes. Será entonces candidato para ser incluido en la distribución de pruebas: Testing — un grupo de paquetes de Unstable elegidos según un criterio cuantificable. Todos los días, un programa selecciona los paquetes a incluir en Testing según elementos que garanticen cierto nivel de calidad:

Este sistema no es infalible; se encuentran regularmente errores críticos en los paquetes incluidos en Testing. Aún así, generalmente es efectivo y Testing tiene muchos menos problemas que Unstable, convirtiéndola para muchos en un buen compromiso entre estabilidad y novedad.

Supongamos ahora que nuestro paquete se incluye en Testing. Mientras tenga margen de mejora, el responsable del mismo debe continuar mejorando y volver a inicar el proceso desde Unstable (aunque generalmente su posterior inclusión en Testing será más rápida: a menos que haya cambiado significativamente todas sus dependencias ya se encuentran disponibles). El desarrollador completa su trabajo cuando alcanza la perfección. El siguiente paso es la inclusión en la distribución Stable que, en realidad, es una simple copia de Testing en un momento elegido por el administrador de versión. Lo ideal sería que esta decisión se tome cuando esté listo el instalador y cuando no exista ningún programa en Testing que tenga errores críticos conocidos.

Ya que este momento nunca llega realmente, en la práctica Debian llega a un compromiso: eliminar paquetes en los que su encargado no corrigió los errores a tiempo o acordar publicar una versión con algunos errores en los miles de programas. El gestor de versiones habrá anunciado previamente un período de estabilización («freeze»), durante el cual cada actualización a Testing debe ser aprobado. El objetivo aquí es evitar cualquier versión nueva (y nuevos errores) y sólo aprobar correcciones de errores.

Tras el lanzamiento de una nueva versión estable, los gestores de versiones estables gestionan todos los desarrollos posteriores (denominados "revisiones", por ejemplo: 10.1, 10.2, 10.3 para la versión 10). Estas actualizaciones incluyen sistemáticamente todos los parches de seguridad. También incluirán las correcciones más importantes (el responsable de un paquete debe demostrar la gravedad del problema que desea corregir para que se incluyan sus actualizaciones).

Al final del viaje, nuestro paquete hipotético ahora está incluido en la distribución estable. Este viaje, con sus dificultados, explica las demoras significativas que separan las versiones estables de Debian. Esto contribuye, en general, a su reputación de calidad. Lo que es más, la mayoría de los usuarios son satisfechos utilizando una de las tres distribuciones disponibles simultáneamente. Los administradores de sistemas no necesitan la última y mejor versión de GNOME preocupados por la estabilidad de sus servidores por sobre todas las cosas; ellos pueden elegir Debian Stable y estarán satisfechos. Los usuarios finales, más interesados en las últimas versiones de GNOME o KDE Plasma que en una estabilidad sólida, encontrarán en Debian Testing un buen compromiso entre la falta de problemas serios y software relativamente actualizado. Finalmente, desarrolladores y usuarios más experimentados pueden liderar el camino probando todos los últimos desarrollos en Debian Unstable recién salidos del horno, arriesgándose a sufrir dolores de cabeza y errores inherentes en cualquier nueva versión de un programa. ¡A cada quien su propio Debian!

Cada versión estable (Stable) tiene una esperanza de vida de unos 5 años y, dado que se tiende a liberar una nueva versión cada 2 años, pueden haber hasta 3 versiones soportadas en un mismo momento. Cuando se publica una nueva versión, la distribución predecesora pasa a Oldstable y la que lo era antes pasa a ser Oldoldstable.

Este soporte a largo plazo (LTS) de las vereisones de Debian es una iniciativa reciente: colaboradores individuales y empresas han unido fuerzas para crear el equipo Debian LTS. Las versiones antiguas que ya no son soportadas por el equipo de seguridad de Debian pasan a ser responsabilidad de este nuevo equipo.

El equipo de seguridad de Debian se encarga del soporte de seguridad en la versión Estable actual y también en la versión versión antigua estable (pero sólo durante el tiempo necesario para asegurar un año de solapamiento con la versión estable actual). Esto equivale aproximadamente a tres años de soporte para cada versión. El equipo de Debian LTS se encarga de los últimos (dos) años de soporte de seguridad para que cada versión se beneficie de al menos 5 años de soporte y para que los usuarios puedan actualizarse de la versión N a N+2, por ejemplo, de Debian 9 Stretch a Debian 11 Bullseye.