De mogelijkheid om de nummering en de methode voor het vormen van X.Org Server-releases te wijzigen wordt overwogen

Adam Jackson, die verantwoordelijk was voor verschillende eerdere releases van X.Org Server, hij bood in zijn verslag op de conferentie XDC2019 overstappen op het nieuwe uitgiftenummeringsschema. Om duidelijker te zien hoe lang geleden dit of dat nummer is gepubliceerd, naar analogie met Mesa, werd voorgesteld om het jaar weer te geven in het eerste nummer van de versie. Het tweede getal geeft het significante releasenummer voor het betreffende jaar aan, en het derde getal geeft corrigerende updates weer.

Bovendien zijn releases van X.Org Server nu vrij zeldzaam (X.Org Server 1.20 werd anderhalf jaar geleden uitgebracht) en tot nu toe Niet zichtbaar activiteit op het gebied van de vorming van X.Org Server 1.21, hoewel enkele correcties en innovaties zich in de code hebben opgehoopt, wordt voorgesteld om over te stappen op een gepland model voor de vorming van nieuwe releases.

Het voorstel is dat de codebase continu zal worden ontwikkeld met behulp van een continu integratiesysteem, en dat de release een eenvoudige momentopname zal zijn van de status op bepaalde vooraf geplande data, op voorwaarde dat alle CI-tests met succes zijn doorstaan.
Het is de bedoeling dat er elke zes maanden belangrijke releases, inclusief nieuwe functies, worden gegenereerd. Naarmate er nieuwe functies worden toegevoegd, wordt ook voorgesteld om tussentijdse builds te genereren die bijvoorbeeld elke twee weken automatisch kunnen vertakken.

Hans de Goede, Fedora Linux-ontwikkelaar bij Red Hat, hij merktedat de voorgestelde methode niet zonder gebreken is - aangezien de X.Org Server sterk gebonden is aan de hardware, zal het niet mogelijk zijn om alle problemen op te vangen via het continue integratiesysteem. Daarom wordt voorgesteld om bovendien een systeem in te voeren voor het blokkeren van releasefouten, in aanwezigheid waarvan de automatische release zal worden uitgesteld, en om de vorming van voorlopige releases te organiseren voor testen vΓ³Γ³r de release. Michel DΓ€nzer, Mesa-ontwikkelaar bij Red Hat, hij merktedat de voorgestelde methode goed is voor snapshots en release-kandidaten, maar niet voor definitieve stabiele releases, ook vanwege de mogelijkheid dat er een ABI-compatibiliteitsbreuk ontstaat in een tussentijdse release.

Bron: opennet.ru

Voeg een reactie