Versionszyklus

This page is a translated version of the page Version lifecycle and the translation is 85% complete.
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎Lëtzebuergesch • ‎català • ‎dansk • ‎español • ‎français • ‎italiano • ‎magyar • ‎occitan • ‎polski • ‎português • ‎português do Brasil • ‎suomi • ‎čeština • ‎русский • ‎українська • ‎العربية • ‎فارسی • ‎සිංහල • ‎中文 • ‎日本語 • ‎한국어

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, dass Wikibetreiber die mediawiki-announce-Mailingliste abonnieren, die Mitteilung von allen Versionen erhält und sicherstellen, 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

Version Status Veröffentlichung Lebensende
1.37.x Zukünftige Version November 2021 November 2022
1.36.x zukünftige Version Mai 2021 Mai 2022
1.35.x (LTS) aktuelle Langzeitsupport-Version 25. September 2020(2020-09-25) September 2023
1.34.x Veraltete Version 19. Dezember 2019(2019-12-19) November 2020
1.33.x veraltete Version 2. Juli 2019(2019-07-02) Juni 2020
1.32.x veraltete Version 11. Januar 2019(2019-01-11) Januar 2020
1.31.x (LTS) unterstützte Langzeitsupport-Version 14. Juni 2018(2018-06-14) Juni 2021
1.30.x Veraltete Version 12. Dezember 2017(2017-12-12) Juni 2019

Versionen in der obigen Tabelle, die als überholt 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 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.37
MediaWiki Release Timeline
  •   Alpha-Version
  •   Release development
  •   Stable release
  •   Long-term support release

Richtlinie zur Veröffentlichung

  • Every point release will include updated i18n files as well as any bug fixes. No new features will be back-ported to point releases and support does not necessarily include bundled extensions and skins in general.
  • Ein Hauptrelease wird alle sechs Monate veröffentlicht.
  • 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.

Verrö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’

Most MediaWiki installations include a significant number of extensions (Wikimedia wikis often have around 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.

Extension maintainers are therefore strongly encouraged to maintain a git branches for each extension version corresponding a MediaWiki version. (Siehe Compatibility#MediaWiki extensions für Einzelheiten.) For extensions hosted in Wikimedia's git repos, such branches (with names such as REL1_30 for MediaWiki 1.30) are created automatically from master when a new MediaWiki version is branched (on the assumption that the extension master is compatible with MediaWiki master at all times). However, it's preferable for the extension maintainer to fix bugs not only in HEAD but also in the oldstable and stable versions (by backporting the fix to the old branches if necessary).

The goal of these rules is that people or organizations installing MediaWiki can rely on installing the newest release of a version and matching extensions by a simple method, e.g. for 1.20.x core by referring to REL1_20 in git.

Siehe auch