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.

Every newly updated package is updated on all Debian mirrors around the world within six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. Most frequently, the maintainer has only one traditional PC and has compiled their package on the amd64 (or i386) architecture (or they opted for a source-only upload, thus without any precompiled package); the autobuilders take over and automatically compile versions for all the other architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.

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.

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 7.1, 7.2, 7.3 for version 7). These updates systematically include all security patches. They will also include the most important corrections (the maintainer of a package must prove the gravity of the problem that they wish to correct in order to have their updates included).

At the end of the journey, our hypothetical package is now included in the stable distribution. This journey, not without its difficulties, explains the significant delays separating the Debian Stable releases. This contributes, over all, to its reputation for quality. Furthermore, the majority of users are satisfied using one of the three distributions simultaneously available. The system administrators, concerned above all about the stability of their servers, don't need the latest and greatest version of GNOME; they can choose Debian Stable, and they will be satisfied. End users, more interested in the latest versions of GNOME or KDE Plasma than in rock-solid stability, will find Debian Testing to be a good compromise between a lack of serious problems and relatively up to date software. Finally, developers and more experienced users may blaze the trail, testing all the latest developments in Debian Unstable right out of the gate, at the risk of suffering the headaches and bugs inherent in any new version of a program. To each their own 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 maneja tanto el soporte relativo a la seguridad para la versión actual Stable (estable) como para la Oldstable (pero solo para asegurar un año de solapamiento después de haber liberado la actual estable). Esto lleva a ofrecer soporte durante tres años para cada versión. El equipo LTS de Debian se encarga de los (dos) últimos años de soporte a la seguridad para que cada versión se beneficie de por lo menos 5 años de soporte y dar tiempo a los usuarios para que puedan actualizar desde la versión N a la N+2.