Product SiteDocumentation Site

1.6. Ciclo de vida de una versión

El proyecto tendrá de tres a seis versiones diferentes de cada programa simultáneamente, llamadas «Experimental» (experimental), «Unstable» (inestable), «Testing» (pruebas), «Stable» (estable), Oldstable (antigua estable) e incluso Oldoldstable (antigua «Oldstable»). Cada una de las corresponde a una fase diferente en el desarrollo. Para entender mejor, veamos la travesía de un programa desde su empaquetado inicial hasta su inclusión en una versión estable de Debian.

1.6.1. El estado experimental: Experimental

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.

1.6.2. El estado inestable: Unstable

Let us turn back to the case of a typical package. The maintainer creates an initial package, which they compile for the Unstable version and place on the ftp-master.debian.org server. This first event involves inspection and validation from the ftpmasters. The software is then available in the Unstable distribution, which is the “cutting edge” distribution chosen by users who are more concerned with having up-to-date packages than worried about serious bugs. They discover the program and then test it.
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.
Compilación de un paquete por los autobuilders

Figura 1.2. Compilación de un paquete por los autobuilders

1.6.3. Migración a Testing

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:
  1. falta de fallos críticos o, al menos, menor cantidad que la versión incluida ya en Testing;
  2. at least 5 days spent in Unstable, which is usually sufficient time to find and report any serious problems (successfully passing the package's own test suite, if it has one, reduces that time);
  3. compilación satisfactoria en todas las arquitecturas oficiales;
  4. dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question;
  5. automatic quality tests of the package (autopkgtest) — if defined — don't show any regression.
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.

1.6.4. La promoción desde Testing a Stable

Let us suppose that our package is now included in Testing. As long as it has room for improvement, its maintainer must continue to improve it and restart the process from Unstable (but its later inclusion in Testing is generally faster: unless it changed significantly, all of its dependencies are already available). When it reaches perfection, the maintainer has completed their work. The next step is the inclusion in the Stable distribution, which is, in reality, a simple copy of Testing at a moment chosen by the Release Manager. Ideally, this decision is made when the installer is ready, and when no program in Testing has any known critical bugs.
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.
El camino de un paquete a través de las varias versiones de Debian

Figura 1.3. El camino de un paquete a través de las varias versiones de Debian

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!
Camino cronológico de un programa empaquetado por Debian

Figura 1.4. Camino cronológico de un programa empaquetado por Debian

1.6.5. El estado de Oldstable y Oldoldstable

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.
The Debian security team handles security support in the current Stable release and also in the Oldstable release (but only for as long as is needed to ensure one year of overlap with the current stable release). This amounts roughly to three years of support for each release. The Debian LTS team handles the last (two) years of security support so that each releases benefits from at least 5 years of support and so that users can upgrade from version N to N+2, for example from Debian 8 "Jessie" to Debian 10 "Buster".