Adam Jackson, responsabile di diverse versioni precedenti di X.Org Server, nella sua relazione alla conferenza passare a un nuovo schema di numerazione delle emissioni. Per vedere più chiaramente quanto tempo fa è stata pubblicata una particolare versione, per analogia con Mesa, è stato proposto di riflettere l'anno nel primo numero della versione. Il secondo numero indicherà il numero di serie della versione significativa per l'anno in questione, mentre il terzo numero rifletterà gli aggiornamenti correttivi.
Inoltre, poiché i rilasci di X.Org Server sono ormai piuttosto rari (X.Org Server 1.20 è stato rilasciato un anno e mezzo fa) e finora attività sulla formazione di X.Org Server 1.21, mentre nel codice si sono accumulate alcune correzioni e innovazioni, si propone di passare ad un modello pianificato per la formazione di nuove release.
La proposta si riduce al fatto che il codice base sarà costantemente sviluppato utilizzando un sistema di integrazione continua e il rilascio sarà una semplice istantanea dello stato in determinate date prestabilite, a condizione che tutti i test CI vengano superati con successo.
Si prevede che rilasci significativi, comprese nuove funzionalità, verranno formati una volta ogni 6 mesi. Man mano che vengono aggiunte nuove funzionalità, si propone anche di creare build intermedie che possano ramificarsi automaticamente, ad esempio una volta ogni due settimane.
Hans de Goede, sviluppatore Fedora Linux presso Red Hat, che il metodo proposto non è privo di inconvenienti: poiché X.Org Server dipende molto dall'hardware, non sarà possibile individuare tutti i problemi attraverso un sistema di integrazione continua. Pertanto, si propone di introdurre ulteriormente un sistema di errori di blocco del rilascio, la cui presenza ritarderà il rilascio automatico, nonché di organizzare la formazione di versioni preliminari per il test prima del rilascio. Michael Dänzer, sviluppatore Mesa presso Red Hat, che il metodo proposto è valido per gli snapshot e i release candidate, ma non per i rilasci finali stabili, anche a causa della possibilità di ottenere una violazione di compatibilità ABI in un rilascio temporaneo.
Fonte: opennet.ru