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

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 nuevo paquete actualizado es actualizado en todas las réplicas de Debian en todo el mundo en seis horas. Los usuarios prueban las correcciones y buscan otros problemas que resulten de las modificaciones. Pueden ocurrir varias modificaciones rápidamente. Durante esos momentos, los robots de compilación automática («autobuilder») entran en acción. Maś frecuentemente, el desarrollador sólo tiene una PC tradicional y compiló sus paquetes en la arquitectura amd64 (o i386); los «autobuilder» se encargan de compilar versiones para todas las otras arquitecturas. Algunas compilaciones pueden fallar, el mantenedor recibirá un reporte de error indicando el problema, que es corregido en las siguientes versiones. Cuando un especialista de esa arquitectura descubre el error, el reporte puede llegar con un parche ya listo para utilizar.
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. al menos 10 días en Unstable, que es suficiente tiempo para encontrar y reportar problemas serios;
  3. compilación satisfactoria en todas las arquitecturas oficiales;
  4. dependencias que puedan ser satisfechas en Testing o que, por lo menos, puedan moverse allí junto al paquete en cuestión.
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

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.
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

Luego de la publicación de una nueva versión estable, el gestor de versiones estables se encarga de todo el desarrollo futuro (llamados «revisiones», por ejemplo: 7.1, 7.2, 7.3 para la versión 7). Estas actualizaciones incluyen sistemáticamente todos los parches de seguridad. También incluirán las correcciones más importantes (el encargado de un paquete deberá demostrar la gravedad del problema que desea corregir para lograr incluir 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 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!
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 uqe 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.