Long-term Support Releases

Hazelcast simplifies your upgrade experience with the introduction of long-term support (LTS) releases. You can upgrade directly from a supported previous release to the LTS release or directly between LTS releases using a rolling upgrade.

LTS releases have been introduced with Hazelcast Platform 5.5. You can upgrade directly from 5.2.x or later to 5.5 without the need to upgrade to each release between your current version and the LTS release. We recommend that you upgrade to 5.5 from the latest available patch for your current release.

Features marked as Beta in the source version are upgraded, but are supported only in a cluster of the source version due to changes that can occur between releases. For further information on rolling upgrade compatibilities, see Compatibility Guarantees.

Between LTS releases, Hazelcast will provide short-term support (STS) releases. You can choose to upgrade directly from one LTS to the next LTS, or you can upgrade from one LTS to each STS release and then from the last STS release to the next LTS release. Before deciding the approach that best suits your needs, consider the following:

LTS STS

Focus on stability.

Focus on innovation.

Consolidates the functionality introduced in all STS releases since the last LTS release. Can include improvements, such as increased capacity limits.

Provides the latest features and bug fixes.

Released every two years.

Released at least twice each year.

Upgrade directly from the previous LTS, or from the STS release that precedes the latest LTS release.

Upgrade from last available STS release only.

For example, if there are three STS releases between LTS releases, you cannot upgrade to the latest LTS unless you have upgraded to all three STS releases.

Full support for three years with the option of extended support for a further year.

Maintenance support until the next STS or LTS release only.

Choose if you value stability over new feature adoption, you want to upgrade less frequently, and you want full or extended support.

Choose if you value new features over stability, you are willing to upgrade several times a year, and you are happy with maintenance support for the life of the STS.

Hazelcast 5.5 LTS

The Hazelcast 5.5 LTS release supports direct upgrade as follows:

Upgrade From LTS Release Support

5.2

5.3

  • IMap data structure. This includes the API, configuration options, and persistence

  • CP subsystem. This includes the API and peristence

  • WAN replication. Ongoing replication is supported during the upgrade. This includes both source and target; however, the source and the target cannot be upgraded simultaneously

Hazelcast has tested WAN Replication to validate the upgrade solution. The test covered two clusters of different versions; for scenarios where WAN Replication is used from a cluster with a version or 5.2, 5.3, or 5.4 to another cluster with a version between 4.0 and 5.4, only the replication to clusters of version 5.2 or later have been tested.

5.4

All features

Mixed-version Clusters

Your LTS release member can join clusters that include members from an earlier supported version. You cannot have members from more than two different minor versions in the same cluster.

The following table provides an example of the behaviour:

Action Member Version Cluster Version Description

Form cluster

5.2

5.2

5.2 cluster forms

Member tries to join cluster

5.3

5.2

5.3 member joins 5.2 cluster

Further member tries to join cluster

LTS

5.2

LTS member identifies that two different minor versions are already in the cluster and rejects joining the cluster

The scenario outlined below can occur because the logic for a mixed-version cluster is introduced in the first LTS release and cannot be enforced by earlier releases. However, this scenario is not supported and results from such a cluster would not be reliable.

Hazelcast recommends that you avoid the following scenario:

Action Member Version Cluster Version Description

Form cluster

5.2

5.2

5.2 cluster forms

Member tries to join cluster

LTS

5.2

Member identifies that only one minor version is already in the cluster and joins the cluster

Further member tries to join cluster

5.3

5.2

Member joins the cluster

High-level Process

The process for upgrading to an LTS release is the same as for a rolling upgrade. To summarize, the process involves the following steps:

  1. For each member in the cluster:

    1. Shut down the member and wait for all partitions to migrate to the rest of the cluster

    2. Upgrade the member’s codebase

    3. Start the member and wait for it to join the cluster

  2. Trigger the rolling upgrade on the cluster

For further information on performing a rolling upgrade, including the steps to take, compatibility guarantees and any constraints, see Rolling Upgrades.

Restart Members on Previous Version

If the version has not successfully upgraded following an upgrade, you can recover to the previous version by restarting the members. This is the case whether the upgrade was done automatically, using the API, or using a script.

To do this, shut down then start each member.