2. El calendario de releases anteriores

Durante el desarrollo de la release 5.X de FreeBSD hubo que aprender en carne propia muchas lecciones que solamente pudieron verse con posterioridad. Los objetivos de la serie 5.X fueron muy ambiciosos. Veamos algunos:

• Ofrecer soporte para máquinas dotadas de multiproceso simétrico (Symmetric MultiProcessing, o SMP)

• Mejoras del rendimiento gracias a la adopción de una nueva estrategia de gestión de recursos en el kernel

• Añadir numerosas arquitecturas de procesador

• Introducción de un nuevo modelo de “threading”

• Introducción de un nuevo “scheduler”

• Añadir soporte de nuevas tecnologías como la gestión de energía (especialmente importante en máquinas portátiles), y sobre todo

• no declarar ninguna versión como STABLE hasta que estas tareas no se hubieran terminado

Esto llevó al problema de que había varios años de diferencia entre el momento en el que 4.X se declaró STABLE y el momento en el que 5.X se llegó a STABLE. Esta circunstancia tuvo diversos efectos no deseados:

• El número funciones cambiadas simultáneamente hizo muy difícil aislar esos cambios para hacerlos compatibles con las versiones anteriores a la creació de la rama STABLE.

• Eso significó que los usuarios que necesitaban imperiosamente una nueva función en particular (por ejemplo el poder ejecutar FreeBSD en hardware moderno) estaban obligados a usar (por ejemplo) FreeBSD 5.2.1 a pesar de que oficialmente era una release de uso exclusivo de desarrolladores, y sin tener en cuenta el hecho de que una release CURRENT no cumplía sus demandas.

• En los casos en los que se consiguió la compatibilidad con versiones anteriores los desarrolladores se encontraron con otro problema al intentar adaptar ciertas características a una versión que ellos mismos hacía tiempo que no usaban como su plataforma de desarrollo principal.

• El retraso también provocó que cuando 5.3 se declaró nueva release STABLE la cantidad acumulada de cambios hizo la actualización complicada.

A decir verdad, nadie estaba contento con el resultado.

Las lecciones que se aprendieron de todo esto fueron:

• Las nuevas releases mayores deben tener meno cambios estructurales importantes y deben publicarse con mayor frecuencia.

• Siempre que sea posible los cambios estructurales deben aislarse unos de otros. Esto obliga a que parte del desarrollo tengan lugar fuera del árbol principal y que se integren solamente cuando no afecten a otros procesos simultáneos de desarrollo.

• Las releases mayores deben tener fecha de salida propia no dependiente de la fecha de entrega asignada a un cambio estructural. Si un cambio estructural no está listo a tiempo se incluirá desactivado por omisión y será incluido en la siguiente release.

Al publicar grupos de cambios más pequeños y de una forma más habitual se intenta también dedicar menos tiempo y esfuerzo aplicando nuevas características de HEAD a a la última versión STABLE (y poder así usar dichas nuevas características en más de una versión mayor); aún más, al estar los cambios más aislados el riesgo de provocar nuevos problemas de seguridad es mucho menor.

Además, el concentrarse en una fecha y no en la consecución de una característica lista para integrarse en el sistema, es más fácil planificar para el futuro tanto para los usuarios como a los desarrolladores de aplicaciones ajenas al proyecto y, cómo no, para los desarrolladores de FreeBSD.

Estas razones (y no el intentar ir a la par de las versiones mayores de otro sistema operativo) son el principal motivo del cambio en el calendario de liberación de versiones de FreeBSD.