Wie entsteht eigentlich eine neue Joomla‑Version? Was passiert, wenn ein Fehler entdeckt oder eine neue Funktion vorgeschlagen wird? Hinter jedem Joomla‑Release steht ein klar organisierter Entwicklungsprozess, an dem Anwender, Tester, Entwickler, Maintainer, Release-Manager, Übersetzer und weitere Mitglieder der internationalen Joomla‑Community beteiligt sind. Vom ersten Issue auf GitHub bis zur Veröffentlichung einer stabilen Version durchläuft jede Änderung zahlreiche Prüf- und Qualitätssicherungsstufen.
Wer Joomla auf einer Unternehmenswebsite, Vereinsseite oder einem umfangreichen Webprojekt einsetzt, sieht am Ende meist nur das fertige Update im Backend. Der Weg dorthin ist jedoch wesentlich komplexer. Fehler müssen reproduziert, neue Funktionen bewertet, Code geschrieben, Pull Requests geprüft, automatische und manuelle Tests durchgeführt, Dokumentationen angepasst und Übersetzungen vorbereitet werden. Erst danach kann eine Änderung Bestandteil eines offiziellen Joomla‑Releases werden. Genau dieser strukturierte Workflow ist ein wichtiger Grund dafür, warum wir seit mehr als 20 Jahren auf Joomla setzen und Erfahrungen aus über 500 Joomla-Websites von Joomla 1.5 bis Joomla 6 gesammelt haben.
Joomla ist ein Open-Source-Content-Management-System. Der Quellcode des CMS ist öffentlich zugänglich und die Entwicklung findet zu einem großen Teil auf GitHub statt. Dort werden Fehler gemeldet, neue Funktionen diskutiert, Änderungen am Programmcode vorgeschlagen und Pull-Requests geprüft.
Grundsätzlich kann sich jeder an der Weiterentwicklung beteiligen. Wer einen Fehler entdeckt, eine Verbesserung vorschlagen möchte oder selbst Code beitragen will, benötigt dafür lediglich einen GitHub-Account.
Die offene Entwicklung bedeutet jedoch nicht, dass Änderungen ungeprüft in den Joomla‑Core gelangen. Jeder Beitrag durchläuft einen strukturierten Prozess. Genau diese Kombination aus Offenheit und kontrollierter Qualitätssicherung gehört zu den Stärken des Joomla-Projekts. Der offizielle Joomla-Entwicklungsworkflow beschreibt diesen Weg von der Meldung bis zum fertigen Release sehr detailliert.
Am Anfang steht häufig ein sogenanntes Issue. Dabei kann es sich um einen vermuteten Fehler, einen Verbesserungsvorschlag oder die Idee für eine neue Funktion handeln.
Ein Issue sollte möglichst genau beschreiben, was beobachtet wurde oder was geändert werden soll. Bei einem Fehler helfen insbesondere konkrete Angaben wie:
Nach der Veröffentlichung ist das Issue für andere Community-Mitglieder sichtbar. Sie können Kommentare ergänzen, Rückfragen stellen oder versuchen, das Problem auf einer eigenen Joomla‑Installation nachzustellen.
Dadurch beginnt bereits die erste Form der Qualitätssicherung: Ein gemeldeter Fehler wird nicht einfach ungeprüft übernommen, sondern von mehreren Personen analysiert.
Nicht jedes Issue ist automatisch ein bestätigter Fehler im Joomla-Core. Manche Probleme entstehen beispielsweise durch ein Template, eine Erweiterung eines Drittanbieters oder eine bestimmte Serverkonfiguration.
Hier kommt die Joomla-Bug-Squad ins Spiel. Ihre Mitglieder analysieren Meldungen, versuchen, Fehler zu reproduzieren, und klassifizieren das Issue.
Dabei geht es unter anderem um Fragen wie:
Je nach Ergebnis wird ein Issue anschließend als Bug, Feature Request oder andere Aufgabenart eingeordnet.
Ein bestätigter Fehler muss früher oder später korrigiert werden. Bei einer neuen Funktion ist die Situation anders. Bevor zusätzlicher Code dauerhaft Bestandteil des Joomla-Cores wird, muss zunächst entschieden werden, ob die Funktion überhaupt zu Joomla passt.
Feature-Requests werden deshalb von den Maintainern bewertet. Dabei spielen unter anderem folgende Fragen eine Rolle:
Solche Entscheidungen können intensive Diskussionen auslösen. Nicht jeder Feature-Request wird angenommen.
Wird eine neue Funktion grundsätzlich freigegeben, bedeutet das außerdem nicht, dass sie sofort umgesetzt wird. Der Vorschlag kann zunächst in einer Warteschlange bleiben, bis sich ein Entwickler findet, der die technische Umsetzung übernimmt.
Ist klar, was geändert werden soll, beginnt die eigentliche Entwicklungsarbeit. Niemand verändert den produktiven Joomla‑Core einfach direkt. Stattdessen wird eine Änderung in einem eigenen Entwicklungszweig programmiert und anschließend als Pull Request, kurz PR, eingereicht.
Ein Pull Request kann sehr unterschiedlich umfangreich sein. Bei einem einfachen Schreibfehler reichen möglicherweise wenige geänderte Zeichen. Bei komplexeren Aufgaben müssen dagegen zunächst Ursachen analysiert, Abhängigkeiten geprüft und umfangreiche Anpassungen vorgenommen werden.
Eine gute Einreichung dokumentiert außerdem:
Auch das offizielle Joomla-Repository unterscheidet inzwischen klar zwischen Bugfixes, Features und Änderungen für kommende Hauptversionen und ordnet diese unterschiedlichen Entwicklungszweigen zu.
Sobald ein Pull Request eingereicht wurde, starten automatische Prüfungen. Für die Betreuung dieser Testinfrastruktur gibt es innerhalb des Joomla-Projekts ein eigenes Automatic-Testing Team.
Die automatisierten Tests prüfen, ob bestimmte Funktionen weiterhin erwartungsgemäß arbeiten und ob der eingereichte Code technische Anforderungen erfüllt.
Schlägt ein Test fehl, muss der Entwickler die Ursache untersuchen und den Pull Request entsprechend überarbeiten.
Werden alle automatischen Prüfungen erfolgreich abgeschlossen, kann das System spezielle Installationspakete erstellen, die bereits die Änderungen des Pull Requests enthalten. Diese Pakete können anschließend auf realen Joomla-Installationen getestet werden.
Automatisierte Tests können viele technische Fehler erkennen. Sie können jedoch nicht vollständig beurteilen, ob eine Lösung langfristig sinnvoll aufgebaut ist.
Deshalb prüfen Joomla-Maintainer den eingereichten Code zusätzlich manuell. Dabei wird unter anderem darauf geachtet, ob:
Maintainer können einen Pull-Request freigeben, Änderungen verlangen oder Verbesserungsvorschläge machen. Häufig entstehen dadurch mehrere Überarbeitungsrunden, bevor eine Lösung als technisch ausgereift gilt.
Ein weiterer wesentlicher Bestandteil der Joomla-Entwicklung sind praktische Tests durch Anwender und Community-Mitglieder.
Grundsätzlich kann jeder Pull-Requests testen. Die Schwierigkeit variiert allerdings stark. Manche Änderungen lassen sich auf einer einfachen Joomla-Testinstallation innerhalb weniger Minuten überprüfen. Andere benötigen spezielle Voraussetzungen, beispielsweise:
Gerade diese praktischen Benutzertests sind ein wichtiger Bestandteil der Qualitätssicherung – und gleichzeitig einer der Engpässe in der Joomla-Entwicklung.
Automatisierte Tests können in Sekunden ausgeführt werden. Für reale Nutzungsszenarien braucht es dagegen Menschen, die Testanweisungen sorgfältig durchführen und ihre Ergebnisse dokumentieren.
Die Joomla‑Community unterstützt diesen Prozess unter anderem über eine eigene PR-Testgruppe auf Mattermost sowie durch Veranstaltungen wie Pizza, Bugs & Fun.
Ein praktischer Test wird nicht nur informell durchgeführt. Das Ergebnis muss im Joomla-Issue-Tracker bestätigt werden.
Tester prüfen zunächst das Verhalten vor der Änderung und anschließend die Version mit dem jeweiligen Pull Request. Nur wenn nachvollziehbar dokumentiert ist, dass das Problem vorher besteht und nach der Änderung behoben wurde, gilt der Test als erfolgreich.
Dadurch entsteht eine nachvollziehbare Dokumentation darüber, wer eine Änderung getestet hat und unter welchen Bedingungen sie funktioniert.
Sobald zwei erfolgreiche Tests im Joomla-Issue-Tracker vorliegen, kann ein Mitglied der Bug-Squad oder des Maintainer-Teams einen Pull-Request auf „RTC – Ready to Commit“ setzen.
RTC bedeutet, dass die Änderung die erforderlichen Prüfungen grundsätzlich bestanden hat und zur Übernahme in den Joomla‑Core bereit ist.
Das bedeutet allerdings noch nicht automatisch, dass der Pull Request sofort übernommen wird.
Bei umfangreichen oder besonders sensiblen Änderungen können weitere Prüfungen notwendig sein. Außerdem entwickelt sich der Joomla‑Core währenddessen weiter. Andere Pull Requests können den betroffenen Bereich verändern oder neue Probleme sichtbar machen.
In einem solchen Fall kann der RTC-Status wieder entfernt werden und der Pull-Request kehrt in den normalen Entwicklungszyklus zurück.
Ein Pull Request mit RTC-Status kann schließlich in den Joomla‑Core übernommen werden. Dieser Vorgang wird als Merge bezeichnet.
An dieser Stelle übernehmen die Release-Manager eine zentrale Rolle. Für jede Joomla-Version gibt es zwei Release-Manager. Sie tragen gemeinsam Verantwortung für die jeweilige Veröffentlichung und entscheiden letztlich, ob und in welcher Joomla‑Version ein Pull Request aufgenommen wird.
Auch bei der kommenden Joomla-Version 6.2 sind zwei Release-Manager benannt: Viviana Menzel und Martin Kopp.
Joomla orientiert sich an den Regeln des Semantic Versioning. Dadurch ist klarer definiert, welche Änderungen in welcher Versionsart veröffentlicht werden können.
Eine Joomla-Versionsnummer wie 6.1.3 besteht aus drei Teilen:
Patch-Releases dienen vor allem der Fehler- und Sicherheitskorrektur. Minor-Versionen können neue Funktionen und Verbesserungen enthalten, ohne die Abwärtskompatibilität innerhalb der Hauptversion unnötig zu brechen.
Größere technische Änderungen, bei denen bestehende Schnittstellen verändert oder entfernt werden müssen, können dagegen für eine neue Major-Version vorgesehen werden.
Das lässt sich aktuell direkt im Joomla-Repository beobachten: Parallel existieren Entwicklungszweige für Joomla 5.4, Joomla 6.1, 6.2, 6.3 und bereits für Joomla 7.
Der aktuelle Entwicklungsplan zeigt den beschriebenen Workflow sehr anschaulich. Für Joomla 6.2 wurden zunächst mehrere Alpha- und Beta-Versionen vorgesehen. Der Release Candidate ist für den 29. September 2026 geplant, die stabile Version Joomla 6.2.0 für den 13. Oktober 2026.
Der Joomla-Projektfahrplan weist ausdrücklich darauf hin, dass sich solche Termine abhängig vom Entwicklungsverlauf und der Verfügbarkeit der ehrenamtlichen Beteiligten noch ändern können.
Ist eine technische Änderung abgeschlossen, bedeutet das noch nicht, dass die Arbeit beendet ist.
Hat ein Pull-Request Auswirkungen auf die Benutzeroberfläche, müssen etwa die Benutzerdokumentation und Hilfetexte aktualisiert werden.
Wird eine neue Klasse oder Methode in den Joomla‑Core aufgenommen, benötigt auch die Entwicklerdokumentation entsprechende Ergänzungen.
Diese Dokumentation ist entscheidend, damit Anwender und Erweiterungsentwickler neue Funktionen verstehen und korrekt einsetzen können.
Joomla wird international eingesetzt und unterstützt zahlreiche Sprachen. Deshalb können selbst kleine Änderungen zusätzliche Arbeit für die Übersetzungsteams erzeugen.
Enthält ein Pull Request neue Sprachschlüssel, müssen diese Texte für die unterschiedlichen Joomla-Sprachpakete übersetzt werden.
Ein neues Eingabefeld im Backend kann damit nicht nur Entwicklungs- und Testarbeit verursachen, sondern gleichzeitig Dokumentation und Übersetzungen für zahlreiche Sprachen erforderlich machen.
Vor der Veröffentlichung einer neuen stabilen Joomla‑Version beginnt eine weitere Phase der Qualitätssicherung.
Die Release-Manager stellen je nach Entwicklungsphase bis zu drei Alpha-Versionen, mehrere Beta-Versionen und anschließend Release-Candidates bereit.
Jetzt geht es nicht mehr nur darum, einzelne Pull-Requests isoliert zu testen. Das CMS‑Release-Team prüft die gesamte Joomla-Version und kontrolliert, ob die vielen zusammengeführten Änderungen auch im Zusammenspiel mit der kompletten Anwendung zuverlässig funktionieren.
Sicherheitslücken stellen innerhalb der Entwicklung einen Sonderfall dar. Details über eine noch ungepatchte Schwachstelle können selbstverständlich nicht öffentlich auf GitHub diskutiert werden.
Für solche Fälle besitzt Joomla das Security Strike Team. Sicherheitskorrekturen werden zunächst vertraulich entwickelt und geprüft.
Auch diese Änderungen durchlaufen vor der Veröffentlichung Tests. Das CMS‑Release-Team kontrolliert die Sicherheitskorrekturen gemeinsam mit den übrigen Bestandteilen eines kommenden Releases.
Erst wenn eine korrigierte Joomla-Version bereitsteht, können Details über geschlossene Sicherheitsprobleme veröffentlicht werden. Dadurch erhalten Website-Betreiber zunächst die Möglichkeit, ihre Installation zu aktualisieren.
Nach Issues, Entwicklung, Pull Requests, automatisierten Tests, Reviews, Benutzertests, Merge, Dokumentation und Übersetzungen kommt schließlich der Moment der Veröffentlichung.
Eine stabile Joomla-Version wird während einer sogenannten Release-Party auf Mattermost erstellt. Community-Mitglieder können teilnehmen und die Veröffentlichung live verfolgen.
Damit wird besonders deutlich, dass hinter einem Joomla-Release nicht nur Programmcode steht. Entwickler, Tester, Maintainer, Release-Manager, Dokumentations-Teams, Übersetzer, Sicherheitsteams und zahlreiche weitere Helfer wirken gemeinsam an einer Version mit.
Wer einen Pull Request erfolgreich beiträgt oder Änderungen testet, beteiligt sich unmittelbar an der Weiterentwicklung des Joomla-CMS.
Contributor werden in den Release Notes der jeweiligen Version aufgeführt. Auch aktuelle Joomla‑Releases weisen Tester und Entwickler namentlich aus und zeigen damit transparent, wer an der jeweiligen Version mitgewirkt hat.
Der Joomla-Entwicklungsworkflow ist nicht nur für Programmierer interessant. Er zeigt Website-Betreibern, wie viel Qualitätssicherung hinter einem Update steckt.
Eine Änderung gelangt nicht deshalb in eine neue Version, weil ein einzelner Entwickler sie für sinnvoll hält. Zahlreiche Prüfungen und unterschiedliche Personen sind daran beteiligt.
Das bedeutet selbstverständlich nicht, dass Software vollständig fehlerfrei sein kann. Kein komplexes Content-Management-System kann das garantieren. Entscheidend ist vielmehr, dass es einen transparenten und strukturierten Prozess gibt, mit dem Probleme erkannt, Lösungen entwickelt, getestet und anschließend kontrolliert veröffentlicht werden.
Genau deshalb sind regelmäßige Joomla‑Updates ein wichtiger Bestandteil des professionellen Betriebs einer Website.
Gerade im geschäftlichen Umfeld begegnet uns gelegentlich die Vorstellung, Open-Source-Software werde von beliebigen Entwicklern ohne klare Verantwortlichkeiten verändert.
Der Joomla-Workflow zeigt das Gegenteil.
Die Mitarbeit ist offen, die Übernahme von Änderungen dagegen kontrolliert. Mehrere organisatorische und technische Ebenen greifen ineinander:
Diese Kombination aus Transparenz, weltweiter Beteiligung und klaren Qualitätsstufen ist ein wichtiger Vorteil des Joomla-Projekts.
Wir beschäftigen uns seit mehr als zwei Jahrzehnten intensiv mit Joomla. Unsere Webdesign-Agentur aus Hannover hat sich bereits früh auf das CMS spezialisiert und inzwischen Erfahrungen aus mehr als 500 Joomla-Websites gesammelt.
Diese Erfahrung reicht von Joomla 1.5 über Joomla 2.5, Joomla 3, Joomla 4 und Joomla 5 bis zur aktuellen Joomla-6-Generation.
In dieser Zeit haben wir zahlreiche technologische Veränderungen begleitet. Anforderungen an PHP, Datenbanken, Sicherheit, Datenschutz, responsives Webdesign, Barrierefreiheit und Suchmaschinenoptimierung haben sich erheblich weiterentwickelt.
Joomla konnte diesen Wandel über viele Jahre begleiten, weil das CMS nicht statisch bleibt. Bestehender Code wird gepflegt, Funktionen werden modernisiert, technische Altlasten entfernt und neue Anforderungen über einen organisierten Entwicklungsprozess integriert.
Der Entwicklungsworkflow zeigt zugleich, warum eine Joomla‑Website nach ihrer Veröffentlichung dauerhaft gepflegt werden sollte.
Neue Versionen enthalten nicht einfach nur zusätzliche Funktionen. Sie bringen Fehlerkorrekturen, Sicherheitsupdates, technische Verbesserungen und Anpassungen an moderne Plattformen mit.
Unsere Kunden mit aktivem Administrationsvertrag erhalten deshalb Joomla‑Updates innerhalb ihrer jeweiligen Joomla‑Versionslinie automatisch im Rahmen der laufenden Betreuung.
Damit bleiben Joomla Core und eingesetzte Erweiterungen möglichst nah an der aktuellen technischen Entwicklung.
Die Entwicklung des Joomla-CMS findet überwiegend öffentlich auf GitHub statt. Dort werden Issues, Pull Requests und unterschiedliche Entwicklungszweige verwaltet.
Grundsätzlich ja. Anwender können Issues eröffnen und Fehler beziehungsweise Verbesserungsvorschläge beschreiben. Eine möglichst genaue und reproduzierbare Beschreibung erleichtert die Bearbeitung.
Die Joomla-Bug-Squad analysiert und klassifiziert gemeldete Probleme. Sie prüft unter anderem, ob ein Fehler reproduzierbar ist und wie groß seine Auswirkungen sind.
Ein Pull Request ist ein Vorschlag zur Änderung des Joomla-Quellcodes. Er enthält den geänderten Programmcode und normalerweise eine Beschreibung sowie Testanweisungen.
Das Automatic-Testing-Team betreut die Infrastruktur für automatisierte Tests. Diese Prüfungen werden bei Pull Requests ausgeführt und helfen dabei, technische Probleme frühzeitig zu erkennen.
Grundsätzlich ja. Viele praktische Tests können auch von erfahrenen Joomla‑Anwendern durchgeführt werden. Manche Änderungen benötigen allerdings spezielle technische Voraussetzungen oder Entwicklungskenntnisse.
RTC steht für „Ready to Commit“. Sobald zwei erfolgreiche Tests im Joomla-Issue-Tracker vorliegen, kann ein berechtigtes Teammitglied einen Pull-Request entsprechend kennzeichnen. Damit gilt er grundsätzlich als bereit für die Übernahme in den Joomla-Core.
Die Maintainer und insbesondere die für eine Version zuständigen Release-Manager spielen dabei eine zentrale Rolle. Für jede Joomla-Version sind zwei Release-Manager vorgesehen.
Ein Release Candidate ist eine weit fortgeschrittene Vorabversion. In dieser Phase steht die Prüfung der geplanten stabilen Version im Mittelpunkt. Neue Funktionen sollten zu diesem Zeitpunkt grundsätzlich nicht mehr kurzfristig ergänzt werden.
Sicherheitsrelevante Änderungen werden nicht öffentlich entwickelt, solange dadurch ungepatchte Installationen gefährdet werden könnten. Das Joomla Security Strike Team bereitet entsprechende Korrekturen vertraulich vor.
Die endgültige stabile Version wird im Rahmen einer Release-Party auf Mattermost erstellt. Mitglieder der Joomla‑Community können diesen Prozess begleiten.
Er zeigt, dass Änderungen am Joomla‑Core nicht unkontrolliert veröffentlicht werden. Tests, Code-Reviews, Maintainer, Release-Manager und spezialisierte Teams sorgen für einen strukturierten Entwicklungs- und Freigabeprozess.
Sie möchten eine neue Joomla‑Website entwickeln, eine ältere Installation modernisieren oder Ihre bestehende Website dauerhaft technisch betreuen lassen? Unsere Webdesign-Agentur aus Hannover unterstützt Unternehmen, Vereine und Organisationen von der Konzeption über die Joomla-Migration bis zur laufenden Administration und Pflege.
Joomla Webdesign | Joomla-Migration | Administration und Pflege | CMS-Templatedesign
