Vom Issue bis zur Veröffentlichung – der Entwicklungs-Workflow bei Joomla

Unser GSoC-Student Reda Muhamed stellte die Frage: Wie funktioniert Joomla eigentlich? Wie findet eine Idee ihren Weg in den Joomla-Core? Die Antwort ist überraschend interessant. Alles beginnt mit einem Issue auf GitHub. Bis ein neues Feature oder ein Bugfix tatsächlich im Joomla-Core landet, sind viele Schritte und viele Menschen beteiligt – Anwender, Tester, Entwickler, Maintainer, Release Manager und viele mehr...

Du hast eine Idee, wie Joomla verbessert werden könnte? Oder du glaubst, einen Fehler gefunden zu haben? Dann kannst du ein Issue auf GitHub eröffnen. GitHub ist der Ort, an dem Joomla entwickelt wird. Wenn du selbst beitragen möchtest, benötigst du lediglich einen GitHub-Account..  

Das Issue

Jeder kann ein Issue eröffnen und eine Idee oder einen Fehler beschreiben – und jedes Issue löst eine kleine Lawine aus

Sobald ein Issue eingereicht wurde, erscheint es in der Liste der offenen Issues auf GitHub. Jeder kann es lesen und kommentieren. Andere Benutzer versuchen möglicherweise, das Problem auf ihrer eigenen Website nachzustellen, stellen Rückfragen, diskutieren die Ursache, bestätigen den Fehler oder unterstützen deine Idee in den Kommentaren.

Die Bug Squad

Nicht alle Issues sind gleich. Manche sind sehr einfach, etwa ein Tippfehler in einer Fehlermeldung. Andere erfordern tiefgehende technische Kenntnisse und umfangreiche Fehlersuche.

Hier kommt die Joomla Bug Squad ins Spiel. Die Mitglieder dieses Teams wissen, wie man Fehler analysiert und reproduziert. Sie entscheiden, ob ein Issue gültig ist, und klassifizieren es. Handelt es sich um einen Bug, untersuchen sie beispielsweise:

• Ist der Fehler schon länger vorhanden oder neu?
• Wie groß ist die Auswirkung?
• Wie viele Installationen sind betroffen?

Wird ein Issue als Feature Request eingestuft, gelangt es in den Feature-Workflow. Nicht immer ist die Entscheidung einfach, und manchmal gibt es kontroverse Diskussionen.

Der Feature Workflow

Während Fehler früher oder später behoben werden müssen, benötigen neue Funktionen zusätzliche Diskussionen und eine formelle Zustimmung..

Das Team der Maintainer bewertet jeden Feature Request:

• Ist es eine Funktion, die Joomla enthalten sollte?
• Führt sie zu einem Bruch der Abwärtskompatibilität (Backward Compatibility, b/c)?
• Welche Auswirkungen hätte sie auf bestehende Websites und Erweiterungen von Drittanbietern?

Solche Themen werden regelmäßig in speziellen Meetings diskutiert, bevor eine Entscheidung getroffen wird.

Manche Feature Requests werden abgelehnt. Wird ein Vorschlag angenommen, landet er zunächst in einer Warteschlange – manchmal für längere Zeit, bis sich ein Entwickler darum kümmern kann.

Entwicklung – der Pull Request (PR)

Ist ein Fehler bestätigt, muss jemand den entsprechenden Code schreiben. Jeder Entwickler kann Code zu Joomla beitragen. Natürlich kann niemand den Joomla-Core direkt verändern, aber jeder kann Änderungen vorschlagen und einen Pull Request (PR) erstellen

Manchmal ist das einfach – beispielsweise bei einem Tippfehler in einem Kommentar. Manchmal ist es sehr schwierig: Zunächst muss die Ursache gefunden werden, anschließend muss der Code unter Berücksichtigung aller Joomla-Codierungsrichtlinien und Konzepte geschrieben werden.

Und falls du denkst: „Mit Vibe Coding ist doch nichts schwierig!“ – dann frage ChatGPT zuerst: „Warum ist Vibe Coding bei PRs für Joomla keine gute Idee?“

Qualitätskontrolle – die Maintainer

Automatische Tests

Sobald ein PR eingereicht wird, starten automatische Tests. Dafür gibt es in Joomla ein eigenes Team, das Automatic Testing Team, das die Testwerkzeuge betreut.

Sind alle Tests erfolgreich, erstellt das System Installationspakete mit den Änderungen des PRs. Diese Pakete können von Benutzern heruntergeladen und getestet werden.

Werden Fehler gefunden, schlägt der Test fehl und der Entwickler muss die Probleme beheben.

.

Code Review

Die Maintainer prüfen den Code darauf, ob er den Joomla-Standards entspricht. Sie können den PR freigeben oder Verbesserungsvorschläge machen und Änderungen anfordern.

Benutzertests

Jeder kann jeden PR testen. Manche Tests sind einfach, andere benötigen spezielle Voraussetzungen oder Umgebungen, beispielsweise eine mehrsprachige Website mit Tausenden von Beiträgen. Manche Tests sind so komplex, dass sie praktisch nur von Entwicklern durchgeführt werden können.
Wie man PRs testet, würde den Rahmen dieses Artikels sprengen. Wichtig ist jedoch zu wissen, dass Benutzertests einer der Engpässe in der Joomla-Entwicklung sind Zum Glück gibt es engagierte Tester, eine PR-Testgruppe auf Mattermost sowie die Veranstaltungen „Pizza, Bugs & Fun“. Mach mit!

Ein lesenswerter Artikel dazu ist (englisch): Confessions of an Open Source Tester

Testergebnisse müssen im Joomla Issue Tracker bestätigt werden – und es ist immer ein Erfolgserlebnis, dort auf den Button „Tested“ zu klicken!

Ready to Commit

Sobald zwei erfolgreiche Tests im Issue Tracker vorliegen, kann ein Mitglied der Bug Squad oder des Maintainer-Teams den PR auf „RTC“ (Ready to Commit) setzen. Bei großen oder komplexen PRs kann dieser Zustand lange bestehen bleiben, bis Maintainer und Release Manager eine Entscheidung treffen.
Währenddessen entwickelt sich der Joomla-Core weiter. Andere PRs können Änderungen verursachen oder es werden neue Probleme entdeckt. Dann kann der RTC-Status wieder entfernt werden und der PR kehrt in den Entwicklungszyklus zurück.

Merge

Ein PR mit dem Status „Ready to Commit“ kann in den Joomla-Core übernommen werden. An dieser Stelle kommen die Release Manager ins Spiel. Jede Joomla-Version hat zwei Release Manager. Sie entscheiden letztlich, ob und in welcher Version ein PR aufgenommen wird.

Joomla folgt dabei strengen Regeln nach dem Semantic Versioning (SemVer). Stand Juni 2026 gilt:

* **5.4.x** wird weiterhin unterstützt und erhält alle Fehlerkorrekturen.
* **6.1.x** ist die aktuelle stabile Version und erhält ebenfalls alle Bugfixes.
* **6.2** befindet sich in der Entwicklung. Sie wird die Version 6.1 als stabile Version ablösen und kann kleinere Verbesserungen und neue Funktionen enthalten, solange diese die Abwärtskompatibilität nicht verletzen.
* **7.0** wird bereits vorbereitet. Neue Funktionen, die die Abwärtskompatibilität brechen können, werden für diese Version entwickelt.

Dokumentation

Hat ein PR Auswirkungen auf die Benutzeroberfläche, beispielsweise durch ein neues Eingabefeld in einem Formular, müssen die Benutzerdokumentation und die Hilfetexte entsprechend angepasst werden.

Fügt ein PR neue Klassen oder Methoden zum Core hinzu, muss auch die Entwicklerdokumentation erweitert werden

Übersetzungen

Enthält ein PR neue Sprachschlüssel, wird das Übersetzungsteam aktiv. Für jede von Joomla unterstützte Sprache müssen die neuen Texte übersetzt werden

Release Team

Joomla-Releases sind perfekt organisiert. Keine neue Version erscheint ohne Vorbereitung.

Vor einer stabilen Veröffentlichung erstellen die Release Manager bis zu drei Alpha-Versionen, mehrere Beta-Versionen und Release Candidates.

Das CMS Release Team testet all diese Builds. Dabei wird überprüft, ob die zusammengeführten PRs nicht nur einzeln, sondern auch im Zusammenspiel mit der gesamten Anwendung korrekt funktionieren.

Und – streng geheim – sie testen auch Sicherheitskorrekturen, die vom Security Strike Team bereitgestellt werden.

Endlich - tadaa - das Release

Schließlich wird die neue stabile Version während einer Release-Party auf Mattermost erstellt. Jedes Community-Mitglied kann teilnehmen und das Release live verfolgen.

Wenn dein PR übernommen wurde oder du einen PR getestet hast, bist du ein Joomla-Contributor. Dein Name erscheint in den Release Notes – beispielsweise bei Joomla 6.1.1.

Herzlichen Glückwunsch!

Und jetzt die Frage: Hast du gezählt, wie viele Menschen an einem einzigen Release beteiligt sind?

Originalartikel: https://magazine.joomla.org/issues/2026/june-2026/from-issue-to-release-the-joomla-development-workflow
Bei der Übersetzung hat die KI unterstützt.