Adam Jackson, die verantwoordelijk was voor de voorbereiding van verschillende eerdere releases van X.Org Server, vermeldde in zijn voordracht op de conferentie over te stappen naar een nieuw versiebeheerschema. Om duidelijker te tonen hoe lang geleden een bepaalde release is gepubliceerd, wordt voorgesteld om het jaar in het eerste cijfer van de versie weer te geven. Het tweede cijfer zal het volgnummer van een belangrijke release voor het betreffende jaar aangeven, en het derde cijfer zal correlerende updates weergeven.
Bovendien, aangezien de releases van X.Org Server nu vrij zeldzaam zijn (X.Org Server 1.20 werd anderhalf jaar geleden uitgebracht) en er tot nu toe activiteit is waargenomen voor de vorming van X.Org Server 1.21, terwijl er in de code verschillende fixes en innovaties zijn verzameld, wordt voorgesteld om over te schakelen naar een gepland model voor het maken van nieuwe releases.
Het voorstel houdt in dat de codebasis voortdurend zal worden ontwikkeld met behulp van een continue integratiesysteem, en de release zal een eenvoudige momentopname zijn van de status op bepaalde van tevoren vastgestelde datums, mits alle CI-tests succesvol zijn doorlopen.
Belangrijke releases, inclusief nieuwe mogelijkheden, zijn gepland om eens in de 6 maanden te worden gemaakt. Naarmate nieuwe functies worden toegevoegd, wordt ook voorgesteld om tussentijdse builds te maken, die automatisch kunnen afsplitsen, bijvoorbeeld om de twee weken.
Hans de Goede (Hans de Goede), ontwikkelaar van Fedora Linux die werkt bij Red Hat, , dat de voorgestelde methode niet zonder tekortkomingen is — aangezien X.Org Server sterk afhankelijk is van hardware, zal het via het continue integratiesysteem niet mogelijk zijn om alle problemen te identificeren. Daarom wordt ook voorgesteld om een systeem in te voeren dat blokkerende releasefouten vastlegt, bij aanwezigheid waarvan de automatische release zal worden uitgesteld, evenals het organiseren van het maken van bètaversies voor testen voordat de release plaatsvindt. Michael Dänzer, Mesa-ontwikkelaar bij Red Hat, , merkte op dat de voorgestelde methode goed is voor snapshots en release kandidaten, maar niet voor finale stabiele releases, onder andere vanwege de mogelijkheid dat er een ABI-compatibiliteitsprobleem optreedt in een tussentijdse release.
Bron: opennet.ru
