Elastic Product End of Life Dates
We love all our products, but sometimes we must say goodbye to a release so that we can continue moving forward on future development and innovation. Our End of Life policy defines how long a given release is considered supported, as well as how long a release is considered still in active development or maintenance. We provide more information about support policy, platform support, and support SLAs separately.
The upshot is that we support each major release of our products for 18 months from the General Availability date, and we actively maintain the last minor release of the two most recent major branches of Elasticsearch, and compatible releases of Kibana, Logstash, and Beats. The rest of this document describes this philosophy in more details and provides concrete examples. Tables at the bottom of this page detail maintenance schedule for each of our supported products.
Types of Releases
Major versions, such as 1.0.0, 2.0.0, and 5.0.0, provide us with an opportunity to introduce features and break backwards compatibility. Minor versions, such as 1.1.0 and 1.2.0, provide us with an opportunity to introduce features. Maintenance releases, such as 1.1.1 and 1.1.2, fix bugs only. Maintenance activity occurs on all releases, but we focus on the minor release stream (e.g. 1.1.x) to define how long we maintain a particular code line. Active maintenance of a minor release implies that we are fixing bugs and backporting some number of fixes into that code branch.
Our goal is to maintain the most recent minor release from the current major release stream and the most recent minor release from the prior major release stream. We have observed that some users upgrade frequently and stay up to date with our release stream. These users can stay with the latest minor release stream and obtain fixes with the maintenance releases they choose to deploy. For example, these users would follow our Elasticsearch releases with 2.1.0, 2.1.1, 2.2.0, 2.2.1, etc.
We know that not all users upgrade as quickly as we release. For these users, we maintain the last minor of the prior major release series. For example, with Elasticsearch 1.x, we are maintaining the 1.7.x series for several months. This allows these users to obtain fixes while making only minor changes to their running software. This last minor will be maintained until the release of the second subsequent major version. For example, Elasticsearch 1.7.x will be maintained until the GA release of Elasticsearch 5.0.0. At the release of Elasticsearch 5.0.0, we will continue to maintain the last 2.x series, and begin maintaining the 5.0.x minor series, then 5.1.x series, then 5.2.x series of minor releases.
From time to time we may backport fixes to other minor release streams. For example, a very serious security bug might be ported to multiple branches. We will use our discretion in deciding to do this, but expect it to be very infrequent.
|Elasticsearch||EOL Date||Maintained Until|
|Kibana||EOL Date||Maintained Until|
Note: For Kibana we have made an exception to this policy. Since Kibana 4.1.x was the last Kibana release to support Elasticsearch 1.x, we have decided to maintain Kibana 4.1.x as if it were the last minor in the prior major release series.
|Logstash||EOL Date||Maintained Until|
|Beats||EOL Date||Maintained Until|
Elastic Cloud Enterprise
|Elastic Cloud Enterprise||EOL Date||Maintained Until|
Note: Elasticsearch clusters and Kibana instances deployed on Elastic Cloud Enterprise respect the individual product EOL dates even when deployed in Elastic Cloud Enterprise.
|Elasticsearch-Hadoop||EOL Date||Maintained Until|
|Logstash Forwarder||EOL Date||Maintained Until|