Adam Jackson, responsabile della preparazione di diverse versioni passate di X.Org Server, nel suo intervento alla conferenza di adottare un nuovo schema di numerazione delle versioni. Per rendere più chiara la data di pubblicazione di ciascuna versione, in analogia a Mesa, si propone di riflettere l'anno nel primo numero della versione. Il secondo numero indicherà il numero progressivo della versione significativa dell'anno in esame, mentre il terzo numero rappresenterà gli aggiornamenti correttivi.
Inoltre, poiché le versioni di X.Org Server ora vengono pubblicate piuttosto raramente (X.Org Server 1.20 è uscito un anno e mezzo fa) e al momento attività per la formazione di X.Org Server 1.21, mentre nel codice si sono accumulati alcuni correttivi e novità, si propone di passare a un modello pianificato di sviluppo di nuove versioni.
La proposta consiste nel fatto che la base di codice si svilupperà costantemente utilizzando un sistema di integrazione continua, e il rilascio rappresenterà semplicemente uno stato della situazione in date prestabilite, a condizione che tutti i test CI siano stati superati con successo.
Le importanti release, che includono nuove funzionalità, verranno programmate ogni 6 mesi. Con l'aggiunta di nuove funzionalità, si prevede anche di creare build intermedie che possono ramificarsi automaticamente, ad esempio ogni due settimane.
Hans de Goede, sviluppatore di Fedora Linux presso Red Hat, , che il metodo proposto non è privo di difetti, poiché l'X.Org Server è molto legato all'hardware e attraverso il sistema di integrazione continua non sarà possibile catturare tutti i problemi. Pertanto, si propone di introdurre un sistema di blocco per gli errori di rilascio, il che comporterebbe il rinvio del rilascio automatico in presenza di tali errori, e di organizzare la creazione di versioni preliminari per il test prima del rilascio. Michel Dänzer, sviluppatore di Mesa presso Red Hat, , ha dichiarato che il metodo proposto è buono per snapshot e candidati al rilascio, ma non per le release finali stabili, anche a causa della possibilità di incorrere in incompatibilità ABI in una release intermedia.
Fonte: opennet.ru
