Versionszyklus

This page is a translated version of the page Version lifecycle and the translation is 94% complete.
Outdated translations are marked like this.

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

Für die vollständige Versionsgeschichte siehe: w:MediaWiki version history.
Version Status Veröffentlichung Lebensende
1.43.x zukünftige Version mit Langzeitunterstützung (LTS)
1.42.x future version
1.41.x aktuelle stabile Version
1.40.x unterstützte 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. The release manager has also issued a strong recommendation that only versions listed above as the current “stable version”, "legacy version" or “long-term support version” be used in a production environment.

Special:MyLanguage/MediaWiki 1.19Special:MyLanguage/MediaWiki 1.20Special:MyLanguage/MediaWiki 1.21Special:MyLanguage/MediaWiki 1.22Special:MyLanguage/MediaWiki 1.23Special:MyLanguage/MediaWiki 1.24Special:MyLanguage/MediaWiki 1.25Special:MyLanguage/MediaWiki 1.26Special:MyLanguage/MediaWiki 1.27Special:MyLanguage/MediaWiki 1.28Special:MyLanguage/MediaWiki 1.29Special:MyLanguage/MediaWiki 1.30Special:MyLanguage/MediaWiki 1.31Special:MyLanguage/MediaWiki 1.32Special:MyLanguage/MediaWiki 1.33Special:MyLanguage/MediaWiki 1.34Special:MyLanguage/MediaWiki 1.35Special:MyLanguage/MediaWiki 1.36Special:MyLanguage/MediaWiki 1.37Special:MyLanguage/MediaWiki 1.38Special:MyLanguage/MediaWiki 1.39Special:MyLanguage/MediaWiki 1.40Special:MyLanguage/MediaWiki 1.41Special:MyLanguage/MediaWiki 1.42
MediaWiki Release Timeline
  •   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). Managing the maintenance bug fixing of extensions and choosing the right version of an extension in cases where the HEAD development version relies on features not yet available in stable or oldstable MediaWiki core, can be challenging.

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.

Von Version 1.36 an unterstützt MediaWiki Upgrades nur in Schritten von vor zwei LTS-Releases (siehe phab:T259771). Upgrades von älteren Versionen von MediaWiki müssen stufenweise erfolgen. Das bedeutet: ein Upgrade von 1.34 oder älter auf 1.41 muss über ein Upgrade auf 1.35 (oder 1.39) erfolgen, um dann auf die gewünschte Version 1.41 zu aktualisieren.

Siehe auch