WordPress 6.8 wird die letzte Version für eine Weile sein… zumindest bis 2026. Es scheint, als würde es künftig nur noch ein einziges großes WordPress-Update pro Jahr geben.

Du kannst diesen Podcast über Pocket Casts, Spotify und Apple Podcasts anhören oder den Feed direkt abonnieren.

Hallo, ich bin Simon Kraft und ihr hört den WP Podcast, mit den wöchentlichen Nachrichten aus der WordPress-Community.

Diese Folge behandelt die Woche vom 31. März bis 6. April 2025

Am 27. März fand ein Treffen mit 30 Core-Contributor*innen statt. Dort wurde festgestellt, dass in den letzten 6 Monaten die Zahl der Tickets für Gutenberg und den WordPress-Core gleich geblieben ist. Die Zahl der geschlossenen Tickets ist seit dem Release von WordPress 6.7 Ende 2024 aber gesunken.

Deshalb ging es in der Sitzung darum, ob die Anzahl der WordPress-Releases reduziert werden sollte. Statt der bisher drei größeren Releases pro Jahr soll es künftig nur noch eines geben.

Im Artikel werden Argumente für und gegen diese Änderung genannt. Nehmen wir uns hier heute doch etwas Zeit, diese Argumente zu betrachten und einem kurzen Fakten-Check zu unterziehen.

Es stimmt, dass ein geringeres Release-Tempo den Druck auf Teams und Mitwirkende reduzieren kann. Das ist besonders jetzt wichtig, wo Verfügbarkeit bezahlter Contributor*innen stark gesunken sind.

Ein angeführter Punkt zur Verbesserung von Dokumentation und Infrastruktur ist ebenfalls realistisch. Die Dokumentation ist aktuell oft lückenhaft, die Infrastruktur veraltet. Weniger Releases könnten hier helfen.

Auch mehr Automatisierung ist plausibel. Weniger Zeitdruck würde Investitionen in Automatisierung ermöglichen. Allerdings sind es meist Leute, die diese Aufgaben übernehmen könnten, bei Automattic angestellt. Und Automattic hat seine Unterstützung für das WordPress-Projekt in den letzten Wochen ja deutlich zurückgefahren.

Größere Releases führen bei Vielen zur Sorge, besonders in einer Community, die sich an kleinere, häufige Updates gewöhnt hat. Einzelne Updates, die viele Änderungen bündeln könnten Zweifel an Stabilität und Kompatibilität aufkommen lassen. Die Hoffnung, dadurch größere Features statt nur Bugfixes einzubauen, ist technisch gesehen aber berechtigt.

Wegen des aktuellen Rückgangs bei den Contributions – auch durch den Rechtsstreit zwischen Automattic und WP Engine – könnten große Releases allerdings schwer umsetzbar sein.

Einige sprechen von Anpassung an den Rhythmus von Firmen wie eBay oder Airbnb. Aber WordPress ist ein offenes, gemeinschaftliches Projekt. Es ist nicht mit großen Privatunternehmen vergleichbar. Außerdem ist bei großen Unternehmen ein viel kleinteiligerer Release-Prozess eher das Mittel der Wahl.

Ein Fokus auf kanonische Plugins und einzelne Komponenten ist sinnvoll. Aber der Erfolg kanonischer Plugins hängt davon ab, wie gut das Projekt organisiert ist und wie viel Unterstützung jedes Plugin bekommt, wenn es sie akut benötigt.

Weniger Releases könnten langsameres Feedback zur Folge haben. Doch auch jetzt ist die Rückmeldung schon langsam – wegen der sinkenden Zahl an Contributions, nicht wegen des Release-Zyklus.

Es heißt, es werde schwerer, gesponserte Contributor*innen zu rechtfertigen. Das ist nur teilweise richtig. Es ist jetzt schon schwer, Unternehmen dazu zu bewegen, .

Und es könnte schlimmer werden, wenn das Projekt langsamer oder weniger relevant erscheint. Eines der Argumente führt an, dass weniger Releases weniger sichtbaren Fortschritt bedeuten könnten. Wenn wir das genauer überdenken passiert aber bereits. Der Rückgang an Contributions und der Rechtsstreit schaden der Außenwirkung des WordPress-Projekts schon jetzt.

Was ist der Vorschlag?

Nach den Gesprächen wurde beschlossen: WordPress 6.8 wird die letzte große Version im Jahr 2025.

Es wird bis 2026 keine weiteren Hauptversionen geben.

Der Gutenberg-Editor erhält weiterhin alle zwei Wochen kleinere Updates. Wer also Verbesserungen im Editor möchte, sollte das Plugin installieren.

Auch WordPress selbst wird weiterhin kleinere Versionen bekommen. Diese enthalten nur kleinere Verbesserungen und Fehlerbehebungen – keine neuen Dateien.

Bei den offiziellen Plugins, den Canonical Plugins, geht es weiter. Dazu zählen Plugins für bevorzugte Sprachen, Zwei-Faktor-Authentifizierung (2FA) und Performance. So sollen Funktionen unabhängig von großen Releases gepflegt und aktualisiert werden.

Zwei wichtige Bereiche zur Verbesserung wurden genannt:

Besseres Sammeln von Feedback, zum Beispiel durch Telemetrie. Damit will man verstehen, wie Funktionen genutzt werden und welchen Wert sie für die Nutzer haben. Dabei muss geprüft werden, ob solche Datensammlungen mit Datenschutzgesetzen wie der DSGVO vereinbar ist.

Außerdem sollen diese kanonischen Plugins besser sichtbar gemacht werden. Zum Beispiel durch Blogposts, Erwähnungen bei großen Events wie State of the Word, oder durch neue Platzierung im Admin-Bereich – etwa unter „Werkzeuge“.

Ein weiteres wichtiges Thema ist das große Backlog mit über 12.000 offenen Tickets. Man will viele davon in kleinere Releases lösen, unabhängig vom Haupt-Release-Zyklus. Alte oder irrelevante Tickets sollen geschlossen oder verschoben werden – mit dem vielsagenden Status „maybelater“.

Das sorgt immer wieder für Diskussionen, weil nicht klar ist, wer entscheidet, was wichtig ist. Ein großes Backlog schadet aber in jedem Fall dem Bild eines gepflegten Open-Source-Projekts. Hier soll eine verbesserte Verwaltung der Tickets also helfen.

Weitere Verbesserungen betreffen die Entwicklung und Wartung: Mehr Fokus auf Tests, stärkere Nutzung von Beta- und Nightly-Versionen, in Zusammenarbeit mit Hosting-Anbietern.

Der Ablauf zwischen SVN- und GitHub-Repositories soll überarbeitet werden. Ziel ist, den Veröffentlichungsprozess für den Core und Gutenberg zu vereinfachen.

Die Verantwortlichkeiten der Maintainer sollen klarer geregelt werden. Teams und Komponenten sollen mehr Eigenverantwortung erhalten, die Release Squads sollen eher moderieren und zur aktiven Teilnahme motivieren.

Zum Thema Barrierefreiheit und Standards: Es muss klarer werden, was verpflichtend ist und was empfohlen wird. Nicht-technische Mitwirkende sollen wieder mehr eingebunden werden.

Viele dieser Expert*innen haben die Community in den letzten Monaten verlassen. Es braucht neue Wege, damit auch Designer*innen, Tester*innen oder Produktmenschen wieder aktiv teilnehmen können.

So oder so ist das ein spannender Moment für das Projekt. Denn abseits der offiziellen Kanäle entstehen neue Vorschläge für die Projekt-Governance.

Im monatlichen Core-Bericht sieht man, dass Indien und asiatische Länder bei Beiträgen zum WordPress-Core weiter wachsen. Gleichzeitig sinken die Zahlen in den USA.

Kurz vor einem neuen Release steigen die Beiträge üblicherweise. Doch im März haben weniger als 200 Menschen beigetragen, obwohl die Zahl der offenen Tickets gestiegen ist.

Das Community-Team hat ein Update angekündigt: Freiwillige bei WordCamps erhalten jetzt Badges für ihre Profile.

Diese Badges sollen die wichtige Arbeit der Freiwilligen würdigen. Bisher bekamen nur Organisator*innen und Vortragende einen Badge. Vergeben werden die Badges von den Orga-Teams direkt über die jeweilige WordCamp-Sites.

Das WordCamp Europe 2025 rückt näher, und das Programm ist bereits veröffentlicht. Wie in den Vorjahren gibt es einen Contributor Day auf den dann zwei Konferenztage mit Vorträgen und Workshops folgen.

Besonders Themen wie Barrierefreiheit und Cyber-Sicherheit stehen im Programm im Fokus. 52 Vortragende aus 23 Ländern nehmen teil.

Vielen Dank fürs Zuhören und bis zur nächsten Woche!

Alle Informationen zu diesem Podcast und alle Links findet ihr wie immer auf wppodcast.de. Außerdem gibt es diesen Podcast in weiteren Sprachen: Katalanisch, Spanisch, Englisch und Portugisisch

Dieser Podcast ist eine Co-Produktion von KrautPress. Er wird unter einer Creative Commons-Lizenz veröffentlicht. Der Text im spanischen Original stammt von Javier Casares. Deutsche Übersetzung, Schnitt und Produktion von mir, Simon Kraft.