Versionszyklus
MediaWiki wendet bei der Softwareentwicklung das Modell der „kontinuierlichen Integration“ an, bei dem Softwareänderungen regelmäßig von den Websites von Wikimedia, wie bspw. die Wikipedia, übernommen und somit produktiv genutzt werden.
Theoretisch werden neue Hauptversionen halbjährlich herausgegeben, und die Zweige der Hauptversionen erhalten ab der ersten Veröffentlichung bis zu einem Jahr lang Sicherheitsupdates. Aus Zeitgründen und wegen der raschen Überarbeitung der Codebasis können wir veraltete Versionen nicht ewig unterstützen, und Sicherheits- und kritische Aktualisierungen werden nicht auf Versionen angewendet, die ihren End-of-Life-Status erreicht haben.
Der Versionsverwalter empfiehlt Wiki-Betreibern dringend, sich auf der Mailingliste mediawiki-announce einzutragen, die über alle Veröffentlichungen informiert wird, um sicherzustellen, dass ihr Wiki die aktuellste Version der Software ausführt. Diese Ankündigungen werden auch auf mediawiki-l und wikitech-l gepostet.
Versionen und ihr Lebensende
| Version | Status | Veröffentlichung | Lebensende |
|---|---|---|---|
| 1.44.x | zukünftige Version | ||
| 1.43.x (LTS) | zukünftige Version mit Langzeitunterstützung (LTS) | ||
| 1.42.x | aktuelle stabile Version | ||
| 1.41.x | unterstützte Version | ||
| 1.40.x | veraltete Version | ||
| 1.39.x (LTS) | aktuelle Version mit Langzeitunterstützung (LTS) | ||
| 1.38.x | veraltete Version |
Versionen in der obigen Tabelle, die als veraltet markiert sind, und solche die dort überhaupt nicht gelistet sind, erhalten keinerlei Sicherheitsreparaturen mehr. Dies umfasst ebenso alle Versionen, die älter als die älteste angegebene Version sind. Sie können schwerwiegende Sicherheitlücken und andere Softwarefehler enthalten, die auch zu Datenbeschädigungen oder -verlust führen könnten. Der Release-Manager hat außerdem die dringende Empfehlung ausgesprochen, dass nur die oben als aktuelle "stabile Version", "Legacy-Version" oder "Long-Term-Support-Version" aufgeführten Versionen in einer Produktionsumgebung verwendet werden sollten.
- Alpha-Version
- Release development
- Stable release
- Long-term support release
Richtlinie zur Veröffentlichung
- Jede Hauptversion beinhaltet erweiterte und verbesserte Übersetzungen von Systemnachrichten sowie Fehlerbehebungen. Es werden keine neuen Funktionalitäten in die Hauptversionen zurückportiert, und der Support von eingebundenen Erweiterungen und Skins wird nicht generell sichergestellt.
- Eine Hauptversion wird alle sechs Monate veröffentlicht.
- Eine Nebenversion (mit Sicherheits- und allgemeinen Fehlerbehebungen, sowie aktualisierten Systemnachrichten) wird jedes Quartal erstellt.
- Ein Long-Term-Support-Release (LTS) wird alle zwei Jahre veröffentlicht. Der LTS-Support wird sich um ein Jahr überschneiden. Zum Beispiel wurde 1.23 bis Mai 2017 unterstützt. 1.27 wurde im Jahr davor veröffentlicht, damit die Menschen sie als LTS zur Verfügung haben, um auf sie umzusteigen und ein Jahr Zeit für den Übergang zu haben.
- Versionshinweise werden immer die Informationsbasis für Neuerungen und Änderungen sein. Das Projekt wird von Freiwilligen vorangetrieben, deshalb ist nicht immer mit Sicherheit zu sagen, was in den nächsten 6 bis 12 Monaten tatsächlich passieren wird.
Veröffentlichungszeitplan
Diese Zeitleiste ist ein Ablaufplan, was vor der Veröffentlichung einer neuen Version passieren muss. Das Datum der tatsächlichen Veröffentlichung erhält ein T (für "time", Zeit, der Veröffentlichung) und das Suffix # (für die Wochenanzahl bis zur Veröffentlichung).
| Relativer Zeitplan | Aufgabe |
|---|---|
| T - 7 | Kündige an, dass der Veröffentlichungszweig in einer Woche erstellt werden wird. Bitte Leute, sicherzustellen, dass alles, was benötigt wird, um sich in Entwicklung befindliche Features zu vervollständigen, vor diesem Zeitpunkt in den Code übernommen wird. Erstelle „MW-X.XX-release“ auf Phabricator. |
| T - 6 | Erstelle den Zweig für Core und alle Erweiterungen auf Gerrit. |
| T - 5 | Wende den X.XX-rc.0-Tag an und veröffentliche den ersten Veröffentlichungskandidaten. |
| T - 4 | Sammle alle Berichte über Fehler und fasse sie auf der Mailingliste zusammen. |
| T - 3 | Wende den X.XX-rc.1-Tag an und veröffentliche den zweiten Veröffentlichungskandidaten. Alle Erweiterungen, die zur Ergänzung des Tarballs vorgeschlagen sind, sollten zu diesem Zeitpunkt im Code sein. Keine Erweiterungsänderungen werden nach diesem Punkt vorgenommen. |
| T - 2 | Sammle alle Berichte über Fehler, behebe sie, entferne neue, nicht vollständige Features die versehentlich enthalten sind, wende den X.XX-rc.2-Tag an und veröffentliche den dritten Veröffentlichungskandidaten. |
| T - 1 | Wiederhole den vorigen Schritt, verwende X.XX-rc.final als Tag und veröffentliche ihn. Keine Backports werden ab diesem Punkt akzeptiert. |
| T | TAGGE das Repositorium mit X.XX und veröffentliche die Version. |
Verwaltung des Erweiterungslebenszyklus’
Die meisten MediaWiki Installationen enthalten eine signifikante Anzahl an Erweiterungen (viele Wikimedia-Wikis nutzen um die 140). Die Verwaltung der Wartung und Fehlerbehebung von Erweiterungen und die Auswahl der richtigen Version einer Erweiterung in Fällen, in denen die HEAD-Entwicklungsversion auf Funktionen angewiesen ist, die im stabilen oder oldstable MediaWiki-Kern noch nicht verfügbar sind, kann eine Herausforderung sein.
Die Unterstützer von Erweiterungen werden daher stark ermuntert, für jede Version der Erweiterung einen korrespondierenden Zweig zur entsprechenden MediaWiki Version anzulegen.
(Siehe Compatibility#MediaWiki extensions für Einzelheiten.)
Für Erweiterungen die in Wikimedia's git-Repos gehosted werden, werden solche Zweige (mit Namen wie REL1_30 für MediaWiki 1.30) automatisch vom master angelegt, wenn ein neuer MediaWiki Versionszweig erstellt wird (immer unter der Annahme, dass der master der Erweiterung mit dem MediaWiki master kompatibel ist).
Auf jeden Fall sollten die Unterstützer von Erweiterungen nicht nur die Hauptversion in HEAD pflegen, sonder alle unterstützten Versionen mit Fehlerbehebungen versorgen, (und ggf. ältere Versionen rückportieren).
Ziel dieser Regeln ist, dass sich Personen oder Organisationen, die ein MediaWiki installieren, darauf verlassen können, dass die Version zur Erweiterung passt, indem die Versionen verglichen werden (z.B. 1.20.x Kern zum passenden REL1_20 in git).
Außerdem vermeidet dies tarballs und zip-Dateien mit nicht relevanten und unvorhersehbaren Namen.
Siehe auch
- Informationen zur Kompatibilität von MediaWiki, insbesondere mit PHP und MySQL
- Regelwerk für stabile Schnittstellen (engl.)
- Versionen auf WikiApiary - Statistik über die Nutzung der verschiedenen Versionen von MediaWiki.