Adam Jackson, responsabile della preparazione di diverse release precedenti di X.Org Server, nel suo intervento alla conferenza di passare a un nuovo schema di numerazione delle versioni. Per visualizzare più chiaramente da quanto tempo è stata pubblicata una determinata release, analogamente a Mesa, si propone di riflettere l'anno nel primo numero della versione. Il secondo numero indicherà il numero ordinali della release significativa per l'anno considerato, mentre il terzo numero rifletterà gli aggiornamenti correttivi.
Inoltre, poiché le release di X.Org Server ora escono piuttosto raramente (X.Org Server 1.20 è uscito un anno e mezzo fa) e finora attività nella formazione di X.Org Server 1.21, mentre nel codice si sono accumulati alcuni bugfix e novità, si propone di passare a un modello programmato per la formazione di nuove release.
La proposta è che la base di codice si sviluppi continuamente utilizzando un sistema di integrazione continua, e la release rappresenterà un semplice snapshot dello stato in date predefinite, a condizione che tutti i test CI siano superati con successo.
Le release significative, che includono nuove funzionalità, sono programmate per essere create ogni sei mesi. Man mano che vengono aggiunte nuove funzionalità, si propone anche di creare build intermedie, che possono essere automaticamente branchate, ad esempio, ogni due settimane.
Hans de Goede, sviluppatore di Fedora Linux che lavora per Red Hat, , che il metodo proposto ha dei difetti: poiché X.Org Server è molto legato all'hardware, non sarà possibile catturare tutti i problemi attraverso il sistema di integrazione continua. Pertanto, si propone di introdurre un sistema di errori bloccanti nelle release, la cui presenza ritarderà il rilascio automatico, e di organizzare la formazione di release preliminari per i test prima del rilascio. Michel Dänzer, sviluppatore di Mesa di Red Hat, , afferma che il metodo proposto è buono per snapshot e candidati per le release, ma non per le versioni finali stabili, anche a causa della possibilità di ottenere una violazione della compatibilità ABI in una release intermedia.
Fonte: opennet.ru
