Wie lange werden ältere Versionen von Elastic-Produkten unterstützt?

Natürlich lieben wir alle unsere Produkte, aber manchmal müssen wir uns doch von einer Version verabschieden, damit wir uns stärker auf die Entwicklung von Neuerungen und Innovationen konzentrieren können. Wie lange eine bestimmte Version unterstützt wird und wie lange an einer Version aktiv Entwicklungen und Nachbesserungen vorgenommen werden, ist in unserer End-of-Life-Richtlinie (EOL-Richtlinie) festgelegt. Weitere Informationen über unsere Support-Richtlinie, die Plattformunterstützung und Support-SLAs stellen wir separat zur Verfügung.

Zusammenfassung

Grundsätzlich unterstützen wir jede Major-Version unserer Produkte 18 Monate lang (ab dem Datum der allgemeinen Verfügbarkeit der Version). Außerdem warten wir aktiv die jeweils neueste Minor-Version der beiden letzten Major-Versionszweige von Elasticsearch sowie die kompatiblen Versionen von Kibana, Beats und Logstash. In den weiteren Abschnitten dieses Dokuments erläutern wir unsere Philosophie genauer und liefern zum besseren Verständnis konkrete Beispiele. Die Tabellen am Seitenende bieten einen detaillierten Überblick über die Wartung der von uns unterstützten Produkte.

Versionsarten

Mit der Veröffentlichung von Major-Versionen, wie 1.0.0, 2.0.0, 5.0.0 6.0.0 und 7.0.0, können wir neue Funktionen einführen und die Abwärtskompatibilität brechen. Minor-Versionen, wie 6.1.0 und 6.2.0, bieten uns die Möglichkeit, neue Funktionen einzuführen. Wartungsversionen, wie 6.1.1 und 6.1.2, enthalten nur Fehlerbehebungen. An allen unseren Versionen werden aktiv Wartungsarbeiten vorgenommen, aber anhand der Minor-Versionen (z. B. 6.1.x) legen wir fest, wie lange wir eine bestimmte Codezeile warten. Die aktive Wartung einer Minor-Version bedeutet, dass wir Fehler beheben und auch Backports von Fixes in diesem Versionszweig vornehmen.

Wartungsrichtlinie

Wir verfolgen das Ziel, die neueste Minor-Version aus dem aktuellen Major-Versionszyklus und die neueste Minor-Version aus dem vorherigen Major-Versionszyklus zu warten. Wir haben festgestellt, dass einige Nutzer häufig Upgrades vornehmen und in Bezug auf unseren Versionszyklus immer auf dem aktuellen Stand sind. Diese Nutzer können beim neuesten Minor-Versionszyklus bleiben und alle gewünschten Fehlerbehebungen mit den Wartungsupdates verwenden. Diese Nutzer würden beispielsweise Updates auf unsere Elasticsearch-Versionen 7.0.0, 7.0.1, 7.2.0 und so weiter vornehmen.

Wir wissen allerdings auch, dass nicht alle Nutzer so häufig ein Upgrade vornehmen, wie wir neue Versionen veröffentlichen. Für diese Nutzer warten wir die neueste Minor-Version aus dem vorherigen Major-Versionszyklus. Bei Elasticsearch 6.x wäre das zum Beispiel die Versionsreihe 6.8.x. Auf diese Weise erhalten alle Nutzer die erforderlichen Fehlerbehebungen, werden ansonsten aber nur mit kleineren Änderungen an ihrer laufenden Software konfrontiert. Diese letzte Minor-Version wird bis zur Veröffentlichung der zweiten nachfolgenden Major-Version gewartet. So wird Elasticsearch 6.8.x so lange gewartet, bis die allgemein verfügbare Version von Elasticsearch 8.0.0 veröffentlicht wird. Nach der Veröffentlichung von Elasticsearch 8.0.0 werden wir weiterhin die letzte 7.x-Reihe warten und mit der Wartung der Minor-Versionen von 8.0.x beginnen. Daraufhin folgen die Versionsreihen für die Minor-Version 8.1.x und anschließend die Versionsreihen für die Minor-Version 8.2.x.

Ab und zu kann es vorkommen, dass wir Korrekturen auf andere Minor-Versionszyklen zurückportieren. Das könnte zum Beispiel notwendig sein, wenn ein schwerwiegender Sicherheitsfehler gefunden wird und wir Updates auf mehrere Versionszweige zurückportieren müssen. Dies entscheiden wir nach eigenem Ermessen, aber Sie können davon ausgehen, dass solche Fälle sehr selten vorkommen werden.

Wartungstabellen

Die unten stehenden Tabellen sind vereinfachte Beschreibungen der oben aufgeführten Richtlinien. Es kann vereinzelt vorkommen, dass wir zum Beispiel eine neue Minor-Version veröffentlichen, nachdem eine neue Major-Version veröffentlicht wurde. In so einem Fall werden die unten stehenden Tabellen überarbeitet und die oben stehenden Richtlinien haben Vorrang. Dazu ein Beispiel: Sollte Elasticsearch 6.8.x veröffentlicht werden und unter "Gewartet bis" wird 8.0.0 angezeigt, könnte dies zu einem späteren Zeitpunkt auf "Gewartet bis 6.9.0" aktualisiert werden, wenn wir nach Veröffentlichung von 7.0.0 noch einen Version 6.9.0 herausgeben. In diesem Fall würde 6.9.0 gewartet werden, bis 8.0.0 veröffentlicht wird, sofern nicht noch eine Version 6.10.0 dazukommt (und so weiter).

Elasticsearch

Kibana

Logstash

Beats

Elastic Cloud Enterprise

Note: Elasticsearch clusters and Kibana instances deployed on Elastic Cloud Enterprise respect the individual product EOL dates even when deployed in Elastic Cloud Enterprise.

Elastic Cloud on Kubernetes

Note: Elasticsearch clusters and Kibana instances deployed on Elastic Cloud on Kubernetes respect the individual product EOL dates even when deployed in Elastic Cloud on Kubernetes.

Elasticsearch-Hadoop

Logstash forwarder

APM server

APM agents

• APM Go Agent EOL
• APM Java Agent EOL
• APM .NET Agent EOL
• APM Node.js Agent EOL
• APM Python Agent EOL
• APM Ruby Agent EOL
• APM JavaScript RUM Agent EOL

Elastic Endpoint Security Lifecycle Policy

Elastic’s policy for Endpoint Security is to support and maintain the current release and one previous release of the Endgame platform. This means that warranties associated with versions that are two or more releases behind the current version are no longer applicable; and Elastic will no longer provide bug fixes, maintenance releases, workarounds, or patches for those versions. Please see the below table for specifics.