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. Unsere End-of-Life-Richtlinie (EOL) legt fest, wie lange eine bestimmte Version unterstützt wird und wie lange an einer Version aktiv Entwicklungen und Nachbesserungen vorgenommen werden. Weitere Informationen über unsere Support-Richtlinie, den Plattform-Support, und Support-SLAs stellen wir separat zur Verfügung.
Zusammenfassung
Grundsätzlich unterstützen wir jede Hauptversion unserer Produkte 18 Monate lang (von dem Datum an gerechnet, ab dem die Version allgemein verfügbar ist). Außerdem nehmen wir aktiv Wartungsarbeiten an den neuesten Minor-Version der beiden letzten Haupt-Branches von Elasticsearch sowie den kompatiblen Versionen von Kibana, Logstash und Beats vor. In den weiteren Abschnitten dieses Dokuments erläutern wir unsere Philosophie genauer und liefern konkrete Beispiele zum besseren Verständnis. Die Tabellen am Seitenende bieten einen detaillierten Überblick über die Wartungsintervalle unserer unterstützten Produkte.
Versionsarten
Mit der Veröffentlichung von Hauptversionen – wie 1.0.0, 2.0.0, 5.0.0 und 6.0.0 – können wir neue Funktionen einführen und die Abwärtskompatibilität brechen. Minor-Versionen – wie 1.1.0 und 1.2.0 – bieten uns die Möglichkeit, neue Funktionen einzuführen. Wartungsupdates – wie 1.1.1 und 1.1.2 – enthalten nur Fehlerbehebungen. An allen unseren Versionen werden aktiv Wartungsarbeiten vorgenommen, aber anhand der Minor-Versionen (z. B. 1.1.x) legen wir fest, wie lange wir eine bestimmte Code-Basis warten. Die aktive Wartung einer Minor-Version bedeutet, dass wir Fehler beheben und auch Backports von Fixes in diesem Branch vornehmen.
Wartungsrichtlinie
Wir verfolgen das Ziel, die neueste Minor-Version aus dem aktuellen Hauptversionszyklus und die neueste Minor-Version aus dem vorherigen Hauptversionszyklus zu warten. Wir haben festgestellt, dass einige Benutzer häufig Updates vornehmen und in Bezug auf unseren Versionszyklus immer auf dem aktuellsten Stand sind. Diese Benutzer können beim neuesten Minor-Versionszyklus bleiben und alle gewünschten Fehlerbehebungen mit den Wartungsupdates verwenden. Diese Benutzer würden beispielsweise Updates auf unsere Elasticsearch-Versionen 6.1.0, 6.1.1, 6.2.0, usw. vornehmen.
Wir wissen allerdings auch, dass nicht alle Benutzer so häufig ein Upgrade vornehmen, wie wir neue Versionen veröffentlichen. Für diese Benutzer warten wir die neueste Minor-Version aus dem vorherigen Hauptversionszyklus. Bei Elasticsearch 5.x wäre das zum Beispiel die Versionsreihe 5.6.x, die über mehrere Monate gewartet wird. Auf diese Weise erhalten alle Benutzer 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 Hauptversion gewartet. Zum Beispiel: Elasticsearch 5.6.x wird so lange gewartet, bis die allgemein verfügbare Version von Elasticsearch 7.0.0 veröffentlicht wird. Nach der Veröffentlichung von Elasticsearch 7.0.0 werden wir weiterhin die letzte 6.x-Reihe warten und mit der Wartung der Minor-Versionen von 7.0.x beginnen. Daraufhin folgen die Versionsreihen für die Minor-Version 7.1.x und anschließend die Versionsreihen für die Minor-Version 7.2.x.
Ab und zu kann es vorkommen, dass wir Korrekturen auf andere Minor-Versionszyklen zurückportieren. Das wäre zum Beispiel der Fall, wenn ein schwerwiegender Sicherheitsfehler auf mehrere Branches portiert wird. Dies entscheiden wir nach eigenem Ermessen, aber du kannst davon ausgehen, dass solche Fälle sehr selten vorkommen werden.
Wartungstabelle
Die unten stehenden Tabellen sind vereinfachte Beschreibungen der oberen Richtlinien. Es kann dazu kommen, dass wir zum Beispiel eine kleinere Version nach der Veröffentlichungen einer größeren Version verfügbar machen. In so einem Fall werden die unten stehenden Tabellen überarbeitet und die oben stehenden Richtlinien haben Vorrang.
Zum Beispiel, sollte Elasticsearch 5.6.x herausgegeben werden und "Maintained Until" zeigt 7.0.0, könnte dies in Zukunft erneuert werden und "Maintained Until" 5.7.0 aufzeigen, für den Fall dass wir Version 5.7.0 nach 6.0.0 erhältlich machen. In diesem Fall würde 5.7.0 erhalten bleiben bis 7.0.0 veröffentlicht wird. Ausnahme ist die Veröffentlichung von Version 5.8.0 und so weiter.
Elasticsearch
| Elasticsearch | EOL Datum | Gewartet bis |
|---|---|---|
| 1.0.x | 2015-08-12 | 1.1.0 |
| 1.1.x | 2015-09-25 | 1.2.0 |
| 1.2.x | 2015-11-22 | 1.3.0 |
| 1.3.x | 2016-01-23 | 1.4.0 |
| 1.4.x | 2016-05-05 | 1.5.0 |
| 1.5.x | 2016-09-23 | 1.6.0 |
| 1.6.x | 2016-12-09 | 1.7.0 |
| 1.7.x | 2017-01-16 | 5.0.0 |
| 2.0.x | 2017-04-28 | 2.1.0 |
| 2.1.x | 2017-05-24 | 2.2.0 |
| 2.2.x | 2017-08-02 | 2.3.0 |
| 2.3.x | 2017-09-30 | 2.4.0 |
| 2.4.x | 2018-02-28 | 6.0.0 |
| 5.0.x | 2018-04-26 | 5.1.0 |
| 5.1.x | 2018-06-08 | 5.2.0 |
| 5.2.x | 2018-07-31 | 5.3.0 |
| 5.3.x | 2018-09-28 | 5.4.0 |
| 5.4.x | 2018-11-04 | 5.5.0 |
| 5.5.x | 2019-01-06 | 5.6.0 |
| 5.6.x | 2019-03-11 | 7.0.0 |
| 6.0.x | 2019-05-14 | 6.1.0 |
| 6.1.x | 2019-06-13 | 6.2.0 |
| 6.2.x | 2019-08-06 | 6.3.0 |
Kibana
| Kibana | EOL Datum | Gewartet bis |
|---|---|---|
| 3.0.x | 2015-09-18 | 3.1.0 |
| 3.1.x | 2015-11-15 | 4.0.0 |
| 4.0.x | 2016-07-19 | 4.1.0 |
| 4.1.x | 2016-11-10 | 5.0.0 |
| 4.2.x | 2017-04-28 | 4.3.0 |
| 4.3.x | 2017-05-24 | 4.4.0 |
| 4.4.x | 2017-08-02 | 4.5.0 |
| 4.5.x | 2017-09-30 | 4.6.0 |
| 4.6.x | 2018-02-28 | 6.0.0 |
| 5.0.x | 2018-04-26 | 5.1.0 |
| 5.1.x | 2018-06-08 | 5.2.0 |
| 5.2.x | 2018-07-31 | 5.3.0 |
| 5.3.x | 2018-09-28 | 5.4.0 |
| 5.4.x | 2018-11-04 | 5.5.0 |
| 5.5.x | 2019-01-06 | 5.6.0 |
| 5.6.x | 2019-03-11 | 7.0.0 |
| 6.0.x | 2019-05-14 | 6.1.0 |
| 6.1.x | 2019-06-13 | 6.2.0 |
| 6.2.x | 2019-08-06 | 6.3.0 |
Logstash
| Logstash | EOL Datum | Gewartet bis |
|---|---|---|
| 1.3.x | 2015-06-11 | 1.4.0 |
| 1.4.x | 2015-09-20 | 1.5.0 |
| 1.5.x | 2016-11-14 | 5.0.0 |
| 2.0.x | 2017-04-28 | 2.1.0 |
| 2.1.x | 2017-05-24 | 2.2.0 |
| 2.2.x | 2017-08-02 | 2.3.0 |
| 2.3.x | 2017-09-30 | 2.4.0 |
| 2.4.x | 2018-02-28 | 6.0.0 |
| 5.0.x | 2018-04-26 | 5.1.0 |
| 5.1.x | 2018-06-08 | 5.2.0 |
| 5.2.x | 2018-07-31 | 5.3.0 |
| 5.3.x | 2018-09-28 | 5.4.0 |
| 5.4.x | 2018-11-04 | 5.5.0 |
| 5.5.x | 2019-01-06 | 5.6.0 |
| 5.6.x | 2019-03-11 | 7.0.0 |
| 6.0.x | 2019-05-14 | 6.1.0 |
| 6.1.x | 2019-06-13 | 6.2.0 |
| 6.2.x | 2019-08-06 | 6.3.0 |
Beats
| Beats | EOL Datum | Gewartet bis |
|---|---|---|
| 1.0.x | 2017-05-24 | 1.1.0 |
| 1.1.x | 2017-07-26 | 1.2.0 |
| 1.2.x | 2017-09-30 | 1.3.0 |
| 1.3.x | 2018-02-28 | 6.0.0 |
| 5.0.x | 2018-04-26 | 5.1.0 |
| 5.1.x | 2018-06-08 | 5.2.0 |
| 5.2.x | 2018-07-31 | 5.3.0 |
| 5.3.x | 2018-09-28 | 5.4.0 |
| 5.4.x | 2018-11-04 | 5.5.0 |
| 5.5.x | 2019-01-06 | 5.6.0 |
| 5.6.x | 2019-03-11 | 7.0.0 |
| 6.0.x | 2019-05-14 | 6.1.0 |
| 6.1.x | 2019-06-13 | 6.2.0 |
| 6.2.x | 2019-08-06 | 6.3.0 |
Elastic Cloud Enterprise
| Elastic Cloud Enterprise | EOL Datum | Gewartet bis |
|---|---|---|
| 1.0.x | 2018-11-28 | 1.1.0 |
| 1.1.x | 2019-05-14 | 1.2.0 |
Hinweis: Elasticsearch-Cluster und Kibana-Instanzen, die auf Elastic Cloud Enterprise eingesetzt werden, respektieren die einzelnen Produktlebenszyklen, auch wenn sie in Elastic Cloud Enterprise eingesetzt werden.
Elasticsearch-Hadoop
| Elasticsearch-Hadoop | EOL Datum | Gewartet bis |
|---|---|---|
| 2.0.x | 2015-11-27 | 2.1.0 |
| 2.1.x | 2016-12-23 | 2.2.0 |
| 2.2.x | 2017-08-02 | 2.3.0 |
| 2.3.x | 2017-10-08 | 2.4.0 |
| 2.4.x | 2018-02-28 | 6.0.0 |
| 5.0.x | 2018-04-26 | 5.1.0 |
| 5.1.x | 2018-06-08 | 5.2.0 |
| 5.2.x | 2018-07-31 | 5.3.0 |
| 5.3.x | 2018-09-28 | 5.4.0 |
| 5.4.x | 2018-11-04 | 5.5.0 |
| 5.5.x | 2019-01-06 | 5.6.0 |
| 5.6.x | 2019-03-11 | 7.0.0 |
| 6.0.x | 2019-05-14 | 6.1.0 |
| 6.1.x | 2019-06-13 | 6.2.0 |
| 6.2.x | 2019-08-06 | 6.3.0 |
Logstash Forwarder
| Logstash Forwarder | EOL Datum | Gewartet bis |
|---|---|---|
| 0.4.0 | 2016-11-07 | Beats 1.0.0 |