Es wird eine Änderung der Nummerierung und der Methode zur Erstellung von Releases für den X.Org Server in Erwägung gezogen

Adam Jackson, der für die Vorbereitung mehrerer früherer Versionen des X.Org Servers verantwortlich war, Alternativen zu den Begriffen „whitelist/blacklist“ und „master/slave“ vor, die für die Verwendung in Spezifikationen bevorzugt werden – anstelle von „master/slave“ wird empfohlen, „primary/secondary“, „leader/follower“, hat in seinem Bericht auf der Konferenz XDC2019 vorgeschlagen, auf ein neues Versionsnummerierungssystem umzusteigen. Um deutlicher zu sehen, wann eine bestimmte Version veröffentlicht wurde, soll die Jahreszahl in der ersten Zahl der Version angegeben werden. Die zweite Zahl wird die ordinale Nummer der bedeutenden Veröffentlichung im betreffenden Jahr angeben, und die dritte Zahl wird die korrigierenden Updates widerspiegeln.

Darüber hinaus erscheinen die Releases des X.Org Servers jetzt recht selten (X.Org Server 1.20 wurde vor anderthalb Jahren veröffentlicht) und es gibt bisher keine Aktivität zur Entwicklung von X.Org Server 1.21, während im Code einige Korrekturen und Neuerungen angefallen sind. Daher wird vorgeschlagen, zu einem planmäßigen Modell zur Erstellung neuer Releases überzugehen.

Der Vorschlag sieht vor, dass die Codebasis kontinuierlich mithilfe eines Continuous Integration-Systems weiterentwickelt wird, und das Release wird einen einfachen Snapshot des Zustands zu vordefinierten Terminen darstellen, vorausgesetzt, alle CI-Tests werden erfolgreich bestanden.
Bedeutsame Releases, die neue Funktionen beinhalten, sollen alle 6 Monate erstellt werden. Mit der Hinzufügung neuer Funktionen sollen auch Zwischenversionen erstellt werden, die automatisch abgezweigt werden können, beispielsweise alle zwei Wochen.

Hans de Goede, Entwickler von Fedora Linux, der bei Red Hat arbeitet, hat angemerkt, dass die vorgeschlagene Methode nicht ohne Nachteile ist — da der X.Org Server stark von der Hardware abhängt, ist es über das Continuous Integration-System nicht möglich, alle Probleme zu erkennen. Daher wird vorgeschlagen, zusätzlich ein System für Blockierungsfehler bei Releases einzuführen, bei deren Vorhandensein die automatische Veröffentlichung verschoben wird, sowie die Organisation der Erstellung von Vorabversionen zum Testen vor dem Release. Michael Dänzer, Entwickler von Mesa bei Red Hat, hat angemerkt, dass die vorgeschlagene Methode gut für Snapshots und Release-Kandidaten ist, jedoch nicht für finale stabile Versionen, auch aufgrund der Möglichkeit, dass es in einer Zwischenversion zu Kompatibilitätsverletzungen der ABI kommen könnte.

Quelle: opennet.ru