Version policyedit
This section describes our version policy for Elasticsearch Service, including:
Available Elastic Stack versionsedit
Elastic Stack uses a versions code that is constructed of three numbers separated by dots: the leftmost number is the number of the major release, the middle number is the number of the minor release and the rightmost number is the number of the maintenance release (e.g., 8.3.2 means major release 8, minor release 3 and maintenance release 2).
You might sometimes notice additional versions listed in the user interface beyond the versions we currently support and maintain, such as release candidate builds and older versions. If a version is listed in the Elasticsearch Service Console, it can be deployed.
New Elastic Stack versionsedit
Whenever a new Elastic Stack version is released, we do our best to provide the new version on our hosted service at the same time. We send you an email and add a notice to the console, recommending an upgrade. You’ll need to decide whether to upgrade to the new version with new features and bug fixes or to stay with a version you know works for you a while longer.
There can be breaking changes in some new versions of Elasticsearch that break what used to work in older versions. Before upgrading, you’ll want to check if the new version introduces any changes that might affect your applications. A breaking change might be a function that was previously deprecated and that has been removed in the latest version, for example. If you have an application that depends on the removed function, the application will need to be updated to continue working with the new version of Elasticsearch.
To learn more about upgrading to newer versions of the Elastic Stack on our hosted service, check Upgrade Versions.
Upgrades or restart for critical issuesedit
We reserve the right to force upgrade or restart a cluster immediately and without notice in advance if there is a critical security or stability issue. Such upgrades happen only within minor versions.
A forced upgrade or restart might become necessary in a situation that:
- Bypasses Shield, where knowing only the cluster endpoint is sufficient to gain access to data.
- Disrupts our ability to effectively manage a cluster in disaster scenarios
- Impairs stability to the point where we cannot guarantee cluster node or data integrity
- Impairs or risks impairing our infrastructure
Release candidates and cutting-edge releasesedit
Interested in kicking the tires of Elasticsearch releases at the cutting edge? We sometimes make release candidate builds and other cutting-edge releases available in Elasticsearch Service for you to try out.
Remember that cutting-edge releases are used to test new function fully. These releases might still have issues and might be less stable than the GA version. There’s also no guaranteed upgrade path to the GA version when it becomes available.
If you’re interested in trying out one of these cutting-edge releases, we don’t recommended upgrading an existing deployment directly. Instead, use a copy of your existing data with a test deployment, first.
Cutting-edge releases do not remain available forever. Once the GA version of Elasticsearch is released, your deployment needs to be removed after a grace period. We cannot guarantee that you will be able to upgrade to the GA version when it becomes available.
End-of-life versionsedit
For Elasticsearch Service, we follow Section 7 of the Elastic Support Services Policy, which defines the support and maintenance policy of the Elastic Stack.
Elastic will provide maintenance for each major release series for the longer of 30 months after the GA date of the major release or 6 months after the GA date of the subsequent major release. Elastic will provide support assistance to Customers for each major release series during the maintenance period and for an additional 6 months after maintenance has ended. Please refer to Section 7 of the Elastic Support Services Policy for further details.