2. Proceso de ingeniería de releases
Las nuevas release de FreeBSD se generan a partir de la rama -STABLE en intervalos de aproximadamente cuatro meses. El proceso comienza a ejecutarse 45 días antes de la fecha de salida, cuando el ingeniero de releases envía un correo eletrónico a las listas de desarrollo de FreeBSD para recordar a los desarrolladores que disponen de tan solo 15 días para integrar nuevos cambios antes de la fase de congelación de código fuente. Durante este periodo de tiempo, muchos desarrolladores realizan lo que se ha dado en llamar “barrido MFC”. MFC significa en inglés “Merge From CURRENT” (Integración desde CURRENT) y describe el proceso de unificación de los cambios aplicados en la rama de desarrollo -CURRENT a nuestra rama -STABLE.
2.1. Revisión de Código
Treinta días antes del lanzamiento de una release dada el repositorio de código fuente
entra en una fase de “code slush” (“código aguanieve”, en el
sentido de no estar aún congelado y ser por tanto ligeramente moldeable). Durante este
período todos los commits de la rama -STABLE deben ser aprobados por el Grupo de
ingeniería de releases <re@FreeBSD.org>. Los cambios permitidos en
esta fase de 15 días de duración son los siguientes:
-
Arreglo de bugs o errores.
-
Actualizaciones de la documentación.
-
Parches relacionados con cualquier tipo de fallo en la seguridad.
-
Cambios pequeños en controladores de dispositivos, tales como la adición de identificadores de dispositivo.
-
Cualquier cambio adicional que el equipo de ingeniería de releases considere justificado, teniendo siempre en cuenta el riesgo potencial que puede conllevar.
Después de los primeros 15 días de código “slush”, se genera una release candidate (candidata a release) o “RC” para su testeo exhaustivo por parte de la comunidad de usuarios y el código fuente entra en la fase de “code freeze” o congelamiento. En este punto resulta mucho más difícil aceptar cambios a menos que se descubran serios fallos de seguridad o bugs importantes. Durante esta fase, se genera al menos una RC cada semana, hasta que la release final ve la luz. Durante el periodo de tiempo comprendido desde el congelamiento del código hasta la generación de la release final, el equipo de ingeniería de releases se comunica constantemente con el equipo del “security officer”, los equipos encargados de mantener la documentación y los mantenedores de ports, para asegurarse de que los distintos componentes necesarios para obtener una release existosa se encuentran disponibles y listos para ser construidos.
2.2. Lista de tareas para la release final.
Cuando todos los problemas encontrados en las releases candidatas se han corregido, se puede comenzar con el procedimiento de “pulimiento o enbellecimiento” de la release final.
2.2.1. Creación de una Rama Release
Como se describe en la introducción, la rama RELENG_X_Y es una característica relativamente nueva de nuestra metodología de generación de releases. El primer paso para crear esta rama consiste en asegurar que el código fuente utilizado “proviene” de la versión más reciente de RELENG_X.
/usr/src# cvs update -rRELENG_4 -P -d
El siguiente paso consiste en crear una etiqueta de rama, (tag), de esta forma se pueden generar diferencias entre el código actual y la rama de inicio fácilmente, utilizando CVS:
/usr/src# cvs rtag -rRELENG_4 RELENG_4_8_BP src
Y a continuación se crea la etiqueta de la rama:
/usr/src# cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src
Nota: Las etiquetas RELENG_* sólo pueden ser utilizadas por los CVS-meisters y los ingenieros de releases.
2.2.2. Elevación del número de versión
Antes de que la release final se puede etiquetar, construir y antes de que vea la luz, se deben modificar los siguientes ficheros de tal forma que reflejen el número de versión correcto:
-
doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml
-
doc/en_US.ISO8859-1/books/porters-handbook/book.xml
-
doc/share/xml/freebsd.ent
-
src/Makefile.inc1
-
src/UPDATING
-
src/gnu/usr.bin/groff/tmac/mdoc.local
-
src/release/Makefile
-
src/release/doc/en_US.ISO8859-1/share/xml/release.dsl
-
src/release/doc/share/examples/Makefile.relnotesng
-
src/release/doc/share/xml/release.ent
-
src/share/examples/cvsup/standard-supfile
-
src/sys/conf/newvers.sh
-
src/sys/sys/param.h
-
src/usr.sbin/pkg_install/add/main.c
-
www/en/docs.xml
-
www/en/cgi/ports.cgi
-
ports/Tools/scripts/release/config
El fichero “release notes” y el fichero “errata” también deben ajustarse de acuerdo con la nueva release (en la rama de la release) y deben cortarse adecuadamente en las ramas stable/currrent):
-
src/release/doc/en_US.ISO8859-1/relnotes/common/new.xml
-
src/release/doc/en_US.ISO8859-1/errata/article.xml
Sysinstall debe actualizarse para que proporcione el número actual de ports disponibles y la cantidad de espacio de disco requerida para instalar dicha colección de ports. Esta información se encuentra almacenada actualmente en el fichero src/release/sysinstall/dist.c.
Después de construir la release se debe actualizar el número almacenado en los siguientes ficheros para anunciar la release al resto del mundo:
-
www/share/xml/includes.release.xml
-
www/share/xml/includes.release.xsl
-
www/en/releases/*
-
www/en/releng/index.xml
-
www/en/news/news.xml
-
www/en/search/web.atoz
-
src/share/misc/bsd-family-tree
2.2.3. Creación de las etiquetas de release
Cuando la release final se encuentra preparada se utiliza el siguiente comando para crear la etiqueta (a modo de ejemplo) RELENG_4_8_0_RELEASE.
/usr/src# cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src
Los gestores de los proyectos de Documentación y de los Ports se responsabilizan del correcto etiquetado de sus respectivos árboles utilizando RELEASE_4_8_0.
Ocasionalmente se puede presentar un apaño o arreglo de última hora justo después de la creación de las etiquetas finales. En la práctica esto no constituye un problema ya que CVS permite cierta manipulación de etiquetados mediante cvs tag -d nombredeetiqueta nombredefichero . Es muy importante que dichos cambios de última hora se etiqueten adecuadamente para que pasen a formar parte de la nueva release. Las releases de FreeBSD deben ser siempre “reproducibles”. Los “hacks” locales dentro del entorno de ingeniería de releases no están permitidos salvo que se efectúen mediante una correcta manipulación y notificación.