Adam Jackson, der für die Vorbereitung mehrerer früherer X.Org Server-Versionen verantwortlich war, berichtet auf der Konferenz über den Übergang zu einem neuen Schema der Versionsnummerierung. Um besser nachvollziehen zu können, wie lange eine bestimmte Version bereits veröffentlicht ist, wurde vorgeschlagen, im ersten Ziffer der Version das Jahr zu reflektieren. Die zweite Ziffer wird die Reihenfolge der bedeutenden Veröffentlichung für das entsprechende Jahr anzeigen, während die dritte Ziffer die Korrekturupdates widerspiegelt.
Darüber hinaus, da die Veröffentlichungen des X.Org Servers nun relativ selten erscheinen (X.Org Server 1.20 wurde vor anderthalb Jahren veröffentlicht) und bislang Aktivität zur Erstellung von X.Org Server 1.21 zu beobachten ist, während im Code einige Verbesserungen und Neuerungen angesammelt wurden, wird vorgeschlagen, zu einem planmäßigen Modell der Veröffentlichung neuer Versionen überzugehen.
Angebot bedeutet, dass der Code kontinuierlich unter Verwendung eines Systems für kontinuierliche Integration weiterentwickelt wird. Die Veröffentlichung wird ein einfacher Schnitt des Zustands zu vorab festgelegten Terminen darstellen, vorausgesetzt, alle CI-Tests wurden erfolgreich bestanden.
Signifikante Releases, die neue Funktionen beinhalten, sollen alle sechs Monate erstellt werden. Mit der Hinzufügung neuer Möglichkeiten sind auch Zwischenversionen angedacht, die automatisch abgezweigt werden können, beispielsweise alle zwei Wochen.
Hans de Goede, ein Entwickler von Fedora Linux, der bei Red Hat arbeitet, , dass die vorgeschlagene Methode nicht ohne Mängel ist – da der X.Org Server stark von der Hardware abhängig ist, können nicht alle Probleme über das System der kontinuierlichen Integration erfasst werden. Daher wird zusätzlich vorgeschlagen, ein System für blockierende Release-Fehler einzuführen, bei dessen Vorliegen die automatische Veröffentlichung verschoben wird, sowie die Organisation von Vorabveröffentlichungen für Tests vor der endgültigen Veröffentlichung. Michel Dänzer, ein Entwickler von Mesa bei Red Hat, , dass die vorgeschlagene Methode gut für Snapshots und Release-Kandidaten ist, jedoch nicht für endgültige stabile Versionen, unter anderem wegen der Möglichkeit, ABI-Inkompatibilitäten in einer Zwischenversion zu erhalten.
Quelle: opennet.ru
