Versionszyklus

From mediawiki.org
This page is a translated version of the page Version lifecycle and the translation is 100% complete.

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 halbjährlich neue Hauptversionen veröffentlicht, wobei die Release-Zweige weiterhin bis zu einem Jahr nach der ersten Veröffentlichung weitere Sicherheitsaktualisierungen erhalten. Aus Zeitmangel und der schnellen Veränderung der Code-Basis können wir überholte Versionen nicht für immer pflegen, daher werden kritische Updates und Sicherheitsaktualisierungen nicht weiter gepflegt, wenn sie das Ende ihres Lebenszyklus’ erreicht haben.

Der Veröffentlichungsmanager empfiehlt Wikibetreibern, die mediawiki-announce Mailingliste zu abonnieren. Sie enthält Mitteilung aller Versionen und stellt sicher, dass ihr Wiki möglichst mit der aktuellsten Version der Software läuft. Diese Ankündigungen werden auch zur mediawiki-l und wikitech-l geschrieben.

Versionen und ihr Lebensende

Für die komplette Versionsgeschichte siehe: w:MediaWiki version history.
Version Status Veröffentlichung Lebensende
1.40.x zukünftige Version (2023-05) (2024-05)
1.39.x (LTS) Zukünftige Langzeitsupport-Version (2022-11) (2025-11)
1.38.x stabile Version (2022-06-02) (2023-06)
1.37.x verbliebene Version (2021-11-18) November 2022
1.36.x Veraltete Version (2021-05-28) (2022-06-03)
1.35.x (LTS) Langzeitsupport-Version (LTS) (2020-09-25) September 2023
1.34.x veraltete Version (2019-12-19) (2020-11-30)

Versionen in der obigen Tabelle, die als veraltet markiert sind, und solche die dort überhaupt nicht gelistet sind, erhalten keinerlei Sicherheitsreparaturen mehr. Sie haben möglicherweise kritische Verwundbarkeiten bei der Sicherheit und andere große Fehler, was auch die Möglichkeit von Datenverlust und/oder anderer Korruption nach sich ziehen kann. Der Versionsverwalter hat außerdem nachdrücklich empfohlen, in einer Produktionsumgebung nur die oben als „aktuelle stabile Version“ oder „unterstützte Langzeitsupport-Version“ (LTS) aufgeführten Versionen zu verwenden.

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.40
MediaWiki Release Timeline
  •   Alpha-Version
  •   Release development
  •   Stable release
  •   Long-term support release


Richtlinie zur Veröffentlichung

  • Jede Hauptversion beinhaltet verbesserte i18-Dateien und Fehlerbehebungen. Es werden keine neuen Funktionalitäten in die Hauptversionen zurückportiert, und der Support von eingebundenen Erweiterungen und Skins wird nicht generell sichergestellt.
  • Ein Hauptrelease wird alle sechs Monate veröffentlicht.
  • Eine Unter-Release (mit Sicherheits- und allgemeinen Fehlerbehebungen, sowie aktualisierten Meldungen) wird jedes Quartal erstellt.
  • Eine Langzeitsupport-Version (LTS) wird alle zwei Jahre veröffentlicht. Es gibt eine einjährige Überschneidung zwischen zwei LTS-Versionen. Etwa wurde 1.23 bis Mai 2017 unterstützt. 1.27 wurde ein Jahr zuvor veröffentlicht, sodass man ein Jahr Zeit hat, um auf die neue LTS-Version umzusteigen.
  • 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 beinhalten um die 140). Das Management der Fehlerbehebung von Erweiterungen und die Zuordnung zur richtigen Hauptversion kann eine Herausforderung sein, insbesondere wenn Funktionalitäten im Mediawiki-Kern betroffen sind, die ggf. nicht zurückportiert wurden.

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.

Seit Version 1.36, unterstützt MediaWiki ausschließlich Upgrades Haupt-Langzeitsupport Releases (LTS, siehe phab:T259771). Upgrades von älteren Versionen von MediaWiki müssen stufenweise erfolgen.

Siehe auch