Whenever a new Elasticsearch version is released, we do our best to provide the new version in Elastic Cloud 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.
Elasticsearch versions are denoted as X.Y.Z, where X is the major version, Y is the minor version, and Z is the patch level or maintenance release. At any given time, the two latest minor versions are guaranteed to be available for deployments of new clusters, such as Elasticsearch 2.4 and 2.3.5. Only the latest patch level within a minor version is usually available for new deployments, such as 2.4.1.
You might sometimes see additional versions listed in the user interface beyond what we guarantee to be available, such as release candidate builds. If versions are listed, they can be deployed.
Interested in kicking the tires of Elasticsearch releases at the cutting edge? Starting with Elasticsearch 5.0 RC1, we’re exposing release candidate builds and other cutting-edge releases on Elastic Cloud 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.
If you’re interested in trying out one of these cutting-edge releases, we don’t recommended upgrading an existing cluster directly. Instead, use one of the methods to restore across clusters to get a cutting edge release deployed to a new cluster.
Cutting-edge releases do not remain available forever. Once the GA version of Elasticsearch is released, your cluster needs to be upgraded. After a grace period during which you can upgrade on your own, we will upgrade any clusters still on the cutting edge release.
In order to be able to deliver new features and keep complexity manageable, we need to be able to discontinue old versions. When a version nears its end-of-life point, you are typically given six months notice in advance to upgrade to one of the available minor versions. Notice is given by email to the operational contacts registered in the Elastic Cloud Console.
If you don’t upgrade to an available minor version within six month, you will be upgraded to the latest available minor version within your current major version. If no minor version within your current major version is available, you are upgraded to an available minor version within the next major version.
The reason for this upgrade policy is that Elastic Cloud is hosting and managing the clusters for you, not just providing support on an incident level. We need to make sure that the running versions are at an acceptable level with regard to stability, resiliency, and security. There is generally no support for versions that have reached their end of life.
For more information on how Elastic supports versions that reach end-of-life, see Elastic Product End of Life Dates.
Normally upgrades are initiated by the customer through the console, but within a minor version, Elastic Cloud does reserve the option to upgrade your cluster to a later patch level at our discretion and without prior notice. There are two main reasons for this: security and critical bugs. Typically these are either bugs that threaten the privacy or the integrity of your data.
If there is a breaking change in a patch level, it is also a bug and a new patch will be considered, unless the breaking change itself was absolutely necessary for security reasons. Upgrading patch levels can also happen as a result of migrating a cluster to new hardware.