Edge and LTS Releases for Mule
Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Consider the following factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
| Channel Type | Release Cadence | Recommended Customer Profile | Differentiators | Support Coverage |
|---|---|---|---|---|
Edge |
Three times per year:
|
|
|
For versions 4.5 to 4.7:
For version 4.8 and later:
|
LTS |
Annual:
|
On-premises:
|
|
For version 4.6 and later:
|
In February, both Edge and LTS release with the same underlying version, including a minor Mule runtime version and new features.
To review the new support policy that aligns with the new release periods and types of releases, see MuleSoft Support Policy.
| The monthly patching process remains unchanged. See Update Patches to Mule. |
Edge Channel
Starting with Mule 4.5, MuleSoft releases Edge versions in February, June, and October. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform.
LTS Channel
Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions annually in February. If you are on Mule 4.4, you are not required to upgrade to Mule 4.6. However, because Mule 4.5 releases in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the End of Extended Support in October 2025. For CloudHub and CloudHub 2.0 customers, once Standard Support for Mule 4.4 ends, if you want to deploy new apps, you must do so on Mule 4.6 LTS or Mule 4.8 Edge. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases.
Switch from an Edge Version to an LTS Version
You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version.
Mule Runtime Release Cadence Support
The following table shows the Mule runtime release cadence support:
| Mule Version | Release Date | Java Version | End of Standard Support | End of Extended Support |
|---|---|---|---|---|
4.8 Edge |
October 2024 |
8, 11, and 17 |
March 2025 |
June 2025 |
4.7 Edge |
June 2024 |
8, 11, and 17 |
October 2024 |
February 2025 |
4.6 LTS |
February 2024 |
8, 11, and 17 |
August 2025 |
February 2026 |
4.6 Edge |
February 2024 |
8, 11, and 17 |
June 2024 |
October 2024 |
4.5 Edge |
October 2023 |
8 and 11 |
February 2024 |
June 2024 |
| If you are a CloudHub or a CloudHub 2.0 customer and you want to create or test Mule 4.6 applications in Anypoint Studio, the Studio version required is the next upcoming release in March. Meanwhile, MuleSoft enables you to deploy new apps in Mule runtime 4.5e version via API, Mule Maven plugin, and Anypoint Platform CLI starting February 14 until April 19. Auto-upgrade from Mule 4.5 Edge to Mule 4.6 Edge for CloudHub and CloudHub 2.0 applications will be performed in April instead of February. See Temporary changes to auto-upgrade and new app deployment for Mule 4.5 Edge. |
Deployment Models and Application Lifecycle Management
Application lifecycle management depends on the deployment model.
| Action | CloudHub and CloudHub 2.0 | Runtime Fabric | Hybrid Standalone |
|---|---|---|---|
Deploy net new apps |
Deploy to the latest minor-patch version available under Standard Support of each channel. |
Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected. |
Deploy while versions are in support period. |
Auto-upgrade |
|
Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions. |
No auto-upgrade capabilities |
Self-upgrade |
The auto-upgrade occurs during a fixed period after MuleSoft releases the version and enforces the force-upgrade. During that period, you can do a manual upgrade.
|
Always available |
Using the Mule Upgrade Tool |
Rollback |
Available to the previously used version |
Available to the previously used version |
Available to the previous used version using the Mule Upgrade Tool. |
Restart apps |
Always |
Always |
Always while the version is within the support period |
Keep running applications |
Until End of Extended Support |
Always |
Always |
End of Extended Support |
Shutdown running apps. |
Cannot deploy new apps |
Can deploy new apps |
Retirement |
Mule apps do not reach End of Life because they are always auto-upgraded. |
When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on. |
When Mule apps reach End of Life, MuleSoft reserves the right to close the connection of the Mule runtime server to Anypoint Platform. |
Supportability |
All Mule apps are under Standard Support. |
Supported while Mule apps are within the assigned support period. |
Supported while Mule apps are within the assigned support period. |
Redeployment / Applying changes / Upgrades |
Supported until End of Extended Support. |
Supported when a build tag is provided. If a build tag is not provided, the application defaults to the latest patch of the minor version being used. If a wrong, invalid, or unsupported build tag is provided, the deployment fails. |
Supported under Hybrid Stansalone. |
Mule Runtime Version Naming Changes
The version naming convention depends on the deployment model you are using. A version increments:
-
MAJOR when a release includes features that introduce breaking changes and backward incompatibility.
-
MINOR when a release includes all new features keeping backward compatibility with previous minors.
-
PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test.
-
BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes.
Cloudhub, Cloudhub 2.0, and Runtime Fabric
The Mule runtime versioning schema for the new release channels is:
Major[numeric] . Minor[numeric] . Patch[numeric] : Build[numeric] Channel[e for edge, nothing for LTS]
Each February, MuleSoft releases both an Edge and an LTS release with the same Major.Minor version. To distinguish the versions, they are represented as:
-
Edge: 4.6.0:1e
-
LTS: 4.6.0:1
Unlike the Hybrid Standalone customer profile, CloudHub, CloudHub 2.0, and Runtime Fabric require regular OS updates, hence the addition of the build enumeration in the full runtime version schema.
Here are examples of the version numbers:
-
Edge: 4.5.0:1e
-
Edge: 4.6.0:1e
-
LTS: 4.6.0:1
Hybrid Standalone
The Mule runtime versioning changes from date-based, for example, 4.4.0-20230317 to semVer as:
Major.Minor.Patch
Here are examples of the version numbers:
-
4.5.1
-
4.5.2
-
4.5.3
Mule runtime does not introduce a semVer increment if there is a month with no fixes.
Here is an example of the versioning schema using different patch and builds:
| Hybrid Standalone | CloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image | ||||
|---|---|---|---|---|---|
Case |
Release Date |
Description |
Patch/Build |
Mule Runtime |
Runtime Manager/Maven/API Tag for New Deployment |
1 |
Oct 3, 2023 |
First release of 4.5.0 |
0th patch and 1st build |
4.5.0 |
4.5.0:1e |
2 |
Nov 7, 2023 |
Second release of 4.5 |
1st patch and 1st build |
4.5.1 |
4.5.1:1e |
3 |
Nov 7, 2023 |
Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric |
1st patch and 2nd build |
N/A |
4.5.1:2e |
4 |
Nov 7, 2023 |
OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric |
1st patch and 3rd build |
N/A |
4.5.1:3e |
5 |
Dec 5, 2023 |
Second patch version of 4.5 |
2nd patch and 1st build |
4.5.2 |
4.5.2:1e |
6 |
Jan 2, 2024 |
Hot fix for a Mule runtime regression |
3rd patch & 1st build |
4.5.3 |
4.5.3:1e |
7 |
Feb 6, 2024 |
Release of new minor |
0th patch and 1st build |
4.6.0 |
4.6.0:1e (Edge) / 4.6.0:1 (LTS) |
The Mule runtime versioning schema uses the following conventions:
-
Patch number in schema
-
In the schema
4.5.X:2e, the patch number is the X. -
The patch number starts from
0, introducing a new minor version. -
The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes.
-
-
Build number in schema
-
In the schema
4.5.1:Ye, the build number is Y. -
The build number starts from
1, introducing the first AMI or Docker image build of the patch. -
The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime.
-