Van issue tot release – hoe de Joomla-ontwikkelworkflow werkt

Onze GSoC-student Reda Muhamed stelde de vraag: hoe werkt de ontwikkeling van Joomla eigenlijk? Hoe vindt een idee uiteindelijk zijn weg naar de Joomla-core? Het antwoord is verrassend interessant.

Alles begint met een issue op GitHub.
In dit artikel ontdek je hoeveel stappen nodig zijn en hoeveel mensen – gebruikers, testers, ontwikkelaars, maintainers, release managers en anderen – betrokken zijn voordat een nieuwe functie of bugfix in de Joomla-core terechtkomt.

Heb je een idee hoe Joomla verbeterd kan worden? Of denk je dat je een bug hebt gevonden? Dan kun je een issue openen op GitHub. GitHub is de plek waar Joomla wordt ontwikkeld. Als je zelf wilt bijdragen, heb je een GitHub-account nodig.

Een issue

Iedereen kan een issue openen en een idee of bug beschrijven. En elk issue zet een hele keten van gebeurtenissen in gang!

Openstaande issues in de Joomla GitHub-repository

Wanneer een issue wordt ingediend, verschijnt het in de issuellijst op GitHub. Iedereen kan het lezen en erop reageren. Sommige gebruikers proberen het probleem op hun eigen website te reproduceren, stellen aanvullende vragen, bespreken het probleem, bevestigen de bug of ondersteunen jouw idee met opmerkingen.

De Bug Squad

Issues verschillen sterk van elkaar. Sommige zijn heel eenvoudig, zoals een typefout in een foutmelding. Andere vereisen diepgaande technische kennis en uitgebreid debugwerk.

Hier komt de Joomla Bug Squad in beeld. De leden van dit team weten hoe ze problemen moeten reproduceren en analyseren. Zij bepalen of een issue geldig is en classificeren het. Als het om een bug gaat, onderzoeken ze onder andere:

• Is het een oude of een nieuwe bug?

• Hoe groot is de impact?

• Hoeveel installaties worden getroffen?

Als het issue wordt geclassificeerd als een feature request, gaat het verder in de feature-workflow. Soms is een beslissing niet eenvoudig en ontstaan er uitgebreide discussies.

De feature-workflow

Van nieuw voorstel via evaluatie en goedkeuring naar implementatie

Terwijl bugs vroeg of laat opgelost moeten worden, vereisen feature requests extra discussie en goedkeuring.

Het team van maintainers beoordeelt elke feature request:

• Is dit een functie die Joomla zou moeten bevatten?

• Veroorzaakt dit een breuk in de backward compatibility (b/c)?

Backward compatibility betekent dat bestaande Joomla-sites en extensies van derden blijven functioneren. Een nieuwe functie mag dat niet onnodig verstoren.

Maintainers bespreken dergelijke onderwerpen regelmatig tijdens speciale vergaderingen voordat een beslissing wordt genomen.

Sommige feature requests worden afgewezen. Wordt een verzoek goedgekeurd, dan komt het in de wachtrij terecht. Soms blijft het daar langere tijd staan totdat een ontwikkelaar ermee aan de slag gaat.

Ontwikkeling – Pull Request (PR)

Zodra een bug is bevestigd, moet iemand de code schrijven. Iedere ontwikkelaar kan code bijdragen aan Joomla. Natuurlijk kan niet zomaar iedereen de Joomla-code aanpassen, maar iedereen kan wijzigingen voorstellen via een Pull Request (PR).

Openstaande PR’s in de GitHub-repository

 

Soms is dat eenvoudig, bijvoorbeeld het corrigeren van een typefout in een commentaarregel. Soms is het erg complex: eerst moet worden uitgezocht wat er precies gebeurt, daarna moet code worden geschreven die voldoet aan alle Joomla-coderichtlijnen en architectuurprincipes.

Denk je: “Met vibe coding is niets moeilijk”? Vraag dan eerst eens aan ChatGPT: “Waarom is vibe coding een slecht idee voor PR’s in Joomla?”

Kwaliteitscontroles – Maintainers

Automatische tests

Zodra een PR wordt ingediend, starten automatisch verschillende tests. Binnen Joomla is er een speciaal team, het Automatic Testing Team, dat verantwoordelijk is voor het beheer van deze testtools.

Als alle automatische tests slagen, genereert het systeem installatiepakketten met de wijzigingen uit de PR. Gebruikers kunnen deze pakketten downloaden en testen. Vinden de tests fouten in de code, dan mislukt de test en moet de ontwikkelaar de problemen oplossen.

Code review

Maintainers beoordelen de code om te controleren of deze voldoet aan de Joomla-standaarden. Ze kunnen de code goedkeuren of verbeteringen voorstellen en om een update vragen.

Gebruikerstests

Iedereen kan een PR testen. Sommige tests zijn eenvoudig, andere vereisen een speciale omgeving, bijvoorbeeld een meertalige website met duizenden artikelen. Sommige tests zijn zo complex dat alleen ontwikkelaars ze kunnen uitvoeren.

Hoe testen precies werkt valt buiten de scope van dit artikel. Wel is het belangrijk te weten dat gebruikerstests een knelpunt vormen binnen de Joomla-ontwikkeling.

Gelukkig zijn er enthousiaste testers die veel helpen. Er bestaat een speciale PR-testgroep op Mattermost en er worden regelmatig Pizza, Bugs and Fun-evenementen georganiseerd. Doe gerust mee!

Lees ook: Confessions of an Open Source Tester.

Testresultaten moeten worden bevestigd in de Joomla Issue Tracker. En geloof ons: het voelt geweldig om op de knop “Tested” te kunnen drukken.

Ready to Commit (RTC)

Zodra er twee succesvolle tests in de issue tracker zijn geregistreerd, kan een lid van de Bug Squad of het maintainerteam de PR de status RTC
(=Ready to Commit) geven.

Bij grote of complexe PR’s met veel codewijzigingen, of wanneer bepaalde onderdelen nog niet volledig duidelijk zijn, kan deze status lange tijd behouden blijven in afwachting van een beslissing van maintainers en release managers.

Ondertussen kan de Joomla-core veranderen door andere PR’s. Ook kan iemand alsnog een fout ontdekken. In dat geval wordt de RTC-status verwijderd en keert de PR terug naar de ontwikkelingscyclus.

Merge

Een PR die klaar is om te committen, kan worden samengevoegd met de Joomla-core. Hier komen de Release Managers in beeld. Elke Joomla-versie heeft twee release managers.

Uiteindelijk bepalen zij of een PR wordt opgenomen en in welke versie dat gebeurt.

Joomla-versies volgen een strikt versiebeleid (SEMVER). Op dit moment (juni 2026) geldt:

• 5.4.x wordt nog ondersteund en ontvangt alle bugfixes.

• 6.1.x is de officiële stabiele versie en ontvangt alle bugfixes.

• 6.2 is in ontwikkeling en zal 6.1 vervangen als volgende stabiele release. Deze versie mag codeverbeteringen en kleine nieuwe functies bevatten die de backward compatibility niet verbreken.

• 7.0 wordt voorbereid voor ontwikkeling. Nieuwe functies die backward compatibility kunnen verbreken worden voor deze versie ontwikkeld.

Documentatie

Heeft jouw PR gevolgen voor gebruikers, bijvoorbeeld een nieuw invoerveld in een formulier? Dan moeten zowel de gebruikersdocumentatie als het helpscherm van dat formulier worden bijgewerkt.

Voegt de PR een nieuwe klasse of methode toe aan de core, dan moet ook de ontwikkelaarsdocumentatie worden uitgebreid.

Vertalingen

Voegt de PR nieuwe taalstrings toe aan de core? Dan komt het vertaalteam in actie. Voor iedere taal waarin Joomla beschikbaar is, moeten vertalers de nieuwe teksten vertalen.

Het Release Team

Releases worden uiterst zorgvuldig georganiseerd. Een nieuwe Joomla-versie verschijnt niet zomaar zonder voorbereiding.

Release managers bereiden doorgaans maximaal drie alpha-versies, beta-versies en release candidates (RC’s) voor voordat een stabiele versie wordt uitgebracht.

Het CMS Release Team test al deze builds grondig. Ze controleren niet alleen of afzonderlijke PR’s werken, maar ook of alle wijzigingen samen correct functioneren binnen de volledige applicatie.

En – strikt geheim – ze testen ook beveiligingsoplossingen die zijn toegevoegd door het Security Strike Team.

En dan… de release!

Uiteindelijk wordt de nieuwe stabiele versie samengesteld tijdens een releaseparty op Mattermost. Iedere communitylid kan deelnemen en de release live volgen.

Als jouw PR is gemerged of als je hebt geholpen met het testen van een PR, ben je officieel een Joomla-contributor. Je naam verschijnt dan in de release-aankondiging, bijvoorbeeld zoals bij versie 6.1.1.

Gefeliciteerd!

En nu een vraag:

Heb jij geteld hoeveel mensen betrokken zijn bij één enkele PR?