Versionszyklus

From MediaWiki.org
Jump to navigation Jump to search
This page is a translated version of the page Version lifecycle and the translation is 84% complete.

Other languages:
Deutsch • ‎English • ‎Lëtzebuergesch • ‎Nederlands • ‎català • ‎dansk • ‎español • ‎français • ‎italiano • ‎magyar • ‎occitan • ‎polski • ‎português • ‎português do Brasil • ‎suomi • ‎русский • ‎українська • ‎العربية • ‎தமிழ் • ‎සිංහල • ‎中文 • ‎日本語 • ‎한국어

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.32.x künftige Version Dezember 2018(2018-12) Dezember 2019(2019-12)
1.31.x (LTS) aktuelle Version 2018-06-14 Juni 2021(2021-06)
1.30.x verbliebene Version 2017-12-12 November 2018(2018-11)
1.29.x Veraltete Version 2017-07-13 September 2018(2018-09)
1.28.x veraltete Version 2016-11-28 November 2017(2017-11)
1.27.x (LTS) verbliebene Version 2016-06-28 Juni 2019(2019-06)
1.26.x Veraltete Version 2015-11-25 November 2016(2016-11)

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. Die Managerin der Releases hat auch eine starke Empfehlung ausgesprochen, dass nur Versionen, die als aktuelle Version oder verbliebene Version obig aufgeführt sind in einer produktiven Umgebung eingesetzt werden sollten.

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 neccessarily 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.
  • Um das Problem der Versionsnotizen zu mildern, veröffentlichen wir in kommenden LTS-Versionen eine Feature-Liste in Bezug auf die letzte LTS-Version sechs Monate vor ihrer Veröffentlichung. Das bedeutet, dass zur Zeit, als 1.26 veröffentlicht wurde, für Benutzer der Version 1.23 eine Ankündigung gemacht wurde, in der stand, was sie für 1.27 erwarten können.


Versionszeitplan

Special:MyLanguage/MediaWiki 1.16Special:MyLanguage/MediaWiki 1.17Special:MyLanguage/MediaWiki 1.18Special: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.33
  •    Alpha-Version
  •    Development (since branch point)
  •    Aktuelle Version
  •    Legacy release
  •    Obsolete release

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. (See Compatibility#MediaWiki extensions for details.) 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.

Externe Links