Logo de UBports

El proyecto UBports anunció una transición hacia un nuevo modelo de generación de lanzamientos, este anuncia se genera debido a que se está enfrentando a desafíos significativos que ha llevado al proyecto replantear el enfoque de lanzamiento.

Y es que desde el nacimiento del proyecto, este ha seguido un modelo de lanzamiento semi-rolling, durante todo ese tiempo no hubo ningún inconveniente con la forma de trabajo, pero se menciona que los problemas comenzaron a seguir al intentar migrar la base a Ubuntu 20.04.

Hacemos este cambio para reducir la fricción en el proceso de desarrollo. Abrirá la oportunidad de proporcionar diferentes versiones compatibles a largo plazo de Ubuntu Touch en el futuro y garantizará que podamos continuar brindando un sistema operativo móvil confiable y actualizado para todos.

Desafíos actuales

Con el modelo actual sobre el que está trabajando UBports, uno de los problemas más grandes con los que se está enfrentando es la «divergencia de código» que se generó al entre Ubuntu 16.04 y Ubuntu 20.04, lo que complicó la integración y creó confusión sobre qué base de código usar para implementar cambios.

Además de ello, UBports menciona que la falta de paquetes individuales dificultó la publicación de correcciones de errores y actualizaciones de seguridad de manera ágil, lo que resultó en retrasos entre la resolución de problemas y su implementación para los usuarios finales. Mientras que para el lanzamiento de actualizaciones se debía detener el desarrollo para garantizar la estabilidad, lo que limitaba la capacidad de introducir nuevas características y mejoras.

Nuevo modelo de lanzamientos

En lugar de utilizar el esquema de lanzamientos en forma de «número OTA nombre_rama», las nuevas versiones del firmware de Ubuntu Touch se desplegarán siguiendo el esquema «año.mes.actualización». En este esquema, el año y el mes corresponden al momento de un lanzamiento importante basado en una nueva rama de Ubuntu.

El número de actualización representará una versión menor que incluirá solo correcciones y mejoras menores. Está planificado que los lanzamientos importantes se realicen una vez cada seis meses, mientras que los lanzamientos intermedios o de actualización se llevarán a cabo cada dos meses.

Se menciona que este nuevo esquema entrará en vigor después de la actualización del proyecto a la base del paquete Ubuntu 24.04. Se espera que la primera versión de Ubuntu Touch basada en Ubuntu 24.04 se lance en junio y se le asignará el número 24.6.0.

Además, cuando se generen las actualizaciones correctivas, se les asignará el número 24.6.1, 24.6.2, y así sucesivamente. En aproximadamente seis meses después del lanzamiento de «Ubuntu Touch 24.6», (alrededor de diciembre de 2024), se lanzará Ubuntu Touch 24.12.0, que ofrecerá nuevas características y cambios con respecto a Ubuntu 24.10. Cada versión principal se suspenderá un mes después de que se forme la nueva versión principal.

Dado que la transición de la rama actual, basada en Ubuntu 20.04, a la base del paquete Ubuntu 24.04 requiere mucho trabajo y estabilización adicional, se espera que la rama Ubuntu Touch Focal sea compatible durante algún tiempo en paralelo con la nueva rama Ubuntu Touch 24.6.

Específicamente, se prevé generar actualizaciones para Ubuntu Touch OTA-5 Focal, OTA-6 Focal, etc., hasta que la nueva rama esté completamente estabilizada. Al mismo tiempo, las actualizaciones OTA para Ubuntu Touch Focal solo incluirán correcciones de errores y vulnerabilidades, mientras que las nuevas funciones se desarrollarán en la rama Ubuntu Touch 24.6.

Por otra parte, UBports menciona que para adaptarse a este nuevo modelo, ha comenzado a trabajar en algunos ajustes en la organización de ramas de los repositorios Git y la configuración del CI:

• La rama main representará el código de desarrollo para la próxima versión de función, mientras que las ramas ubports/<version UT> contendrán el código para las versiones de función y sus actualizaciones menores.
• Eliminaremos las ramas que representan versiones de Ubuntu específicas para evitar confusiones y simplificar el proceso de desarrollo.
• Los cambios y MRs deberán apuntar a la rama main para el desarrollo activo, y se integrarán en las ramas de versión apropiadas según sea necesario.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.