Adam Jackson, responsable de varias versiones anteriores de X.Org Server, en su informe en la conferencia cambiar a un nuevo esquema de numeración de números. Para ver más claramente cuánto tiempo hace que se publicó un lanzamiento en particular, por analogía con Mesa, se propuso reflejar el año en el primer número de la versión. El segundo número indicará el número de serie de la versión importante para el año en cuestión y el tercer número reflejará las actualizaciones correctivas.
Además, dado que los lanzamientos de X.Org Server ahora son bastante raros (X.Org Server 1.20 se lanzó hace un año y medio) y hasta ahora actividad en la formación de X.Org Server 1.21, si bien se han acumulado algunas correcciones e innovaciones en el código, se propone pasar a un modelo planificado para la formación de nuevas versiones.
La propuesta se reduce al hecho de que la base del código se desarrollará constantemente utilizando un sistema de integración continua, y el lanzamiento será una simple instantánea del estado en ciertas fechas programadas previamente, siempre que todas las pruebas de CI se pasen con éxito.
Está previsto realizar lanzamientos importantes, incluidas nuevas funciones, una vez cada 6 meses. A medida que se agregan nuevas funciones, también se propone crear compilaciones intermedias que puedan ramificarse automáticamente, por ejemplo, una vez cada dos semanas.
Hans de Goede, desarrollador de Fedora Linux en Red Hat, que el método propuesto no está exento de inconvenientes: dado que X.Org Server depende en gran medida del hardware, no será posible detectar todos los problemas a través de un sistema de integración continua. Por lo tanto, se propone introducir adicionalmente un sistema de errores de bloqueo de lanzamiento, cuya presencia retrasará el lanzamiento automático, así como organizar la formación de lanzamientos preliminares para probar antes del lanzamiento. Michael Dänzer, desarrollador de Mesa en Red Hat, que el método propuesto es bueno para instantáneas y versiones candidatas, pero no para versiones estables finales, incluso debido a la posibilidad de sufrir una infracción de compatibilidad ABI en una versión provisional.
Fuente: opennet.ru