Managing Mule Runtime Patch Updates for Apps on Runtime Fabric | MuleSoft Documentation
# Managing Mule Runtime Patch Updates for Apps on Runtime Fabric
The following provides important information about Mule runtime engine patch updates and the Mule runtime engine release channels for Anypoint Runtime Fabric.
For a list of patch updates, refer to Mule runtime patch updates for Runtime Fabric.
## Version Rewrite
Version rewrite used to override the build tag specified in a deployment request if the build tag was out of support or invalid. Starting October 3, 2023, version rewrite does not override any specified tags for any version. However, if a Mule app is deployed through the API without a build tag, the latest build is auto-selected.
## Monthly Date-Patch Updates
Once per month, MuleSoft releases a _date-patch update_ , which includes backward-compatible bug fixes to address any issues discovered in Mule runtime engine. The monthly date-patch update might include security patches if the scheduled date is within the security SLA.
The format of the version number for these updates is:
_Major_._Minor_._Patch_ - _Date_
Mule Runtime Version Naming Changes
Here’s an example version number, including the patch date:
`4.3.0:20210101`
The monthly patches update applications only to the latest date-patch. They do not change the runtime version.
### Mule Runtime Patch Updates for Runtime Fabric Schedule
Runtime Fabric runs each application and gateway deployment on a separate Mule runtime instance. By managing the containerized Mule images used for these deployments, Runtime Fabric enables you to upgrade your Mule runtime version for each deployment on the following schedule:
  1. On the first full week of the month, you have access to new date-patches of updated Mule runtime instances.
  2. During the next two weeks, you can redeploy your applications using the newer date-patch to validate its behavior. This is known as a _grace period_.
  3. Beginning on the third full week of the month, you must select the latest date-patch of your chosen Mule runtime version when deploying a new application, or when making a change to an existing application.


Starting with Mule runtime engine version 4.5, you can disable autoupgrades of your Mule apps on redeployment by passing the tag required for version pinning.
During the grace period, you can select earlier date-patch versions until they are no longer available through the Runtime Manager UI but still usable through the API. Note that this behavior changes starting with Mule runtime engine version 4.5 with Edge and LTS channel releases. All build tags are available in the Runtime Manager UI and API.
### Update a Single App to the Latest Runtime Patch Release
Before updating apps in the production environment, update them in the sandbox environment and run required tests.
To update an app to the latest date patch:
  1. In the Runtime Manager navigation menu, click **Applications**.
  2. Under **Deployment Target** , from the **Runtime version** list, select the version tagged `new`:
Although the version number of the update might be the same as the installed version, a later date identifies the update:
  3. If you want to see details about the version, click the **Read release notes** link.
  4. Click **Apply Changes** to update the app.
Runtime Fabric updates the app with the version you selected and displays a message indicating success or failure.
  5. Redeploy your application.
Mule deployments on Runtime Fabric are not automatically patched. You must redeploy your applications to apply the latest date-patch updates.


## 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 | Differentiators | Support Coverage  
---|---|---|---  
Up to three times per year | 
  * Includes new features on a frequent release cadence with shorter maintenance coverage.
  * Versions are not FedRAMP approved.

|  For versions 4.9 and later:
  * Standard Support until one month after the next Edge version is released
  * 3 months of Extended Support

For version 4.8:
  * 5 months of Standard Support
  * 3 months of Extended Support

For versions 4.5 to 4.7:
  * 4 months of Standard Support
  * 4 months of Extended Support

  
Annual:
  * February

| 
  * Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

|  For version 4.6 and later:
  * A minimum of 18 months of Standard Support
  * A minimum of 6 months of Extended Support
|  For versions 4.9 and later:
  * Standard Support until one month after the next Edge version is released
  * 3 months of Extended Support

For version 4.8:
  * 5 months of Standard Support
  * 3 months of Extended Support

For versions 4.5 to 4.7:
  * 4 months of Standard Support
  * 4 months of Extended Support

  
Annual:
  * February

| 
  * Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

|  For version 4.6 and later:
  * A minimum of 18 months of Standard Support
  * A minimum of 6 months of Extended Support

  
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 up to three times a year. 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.
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  
---|---|---|---|---  
February 2025 | August 2026 | February 2027  
4.9 Edge | February 2025 | November 2025 | February 2026  
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  
February 2024 | 8, 11, and 17 | February 2026 | October 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  
MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility with Java 8, 11, and 17.   
---  
## Deployment Models and Application Lifecycle Management
Application lifecycle management depends on the deployment model.
Action | Runtime Fabric  
---|---  
Deploy net new apps | Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.  
Auto-upgrade | Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.  
Self-upgrade | Always available  
Rollback | Available to the previously used version  
Restart apps  
Keep running applications  
End of Extended Support | Cannot deploy new apps  
Retirement | 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.  
Supportability | Supported while Mule apps are within the assigned support period.  
## 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.


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


Runtime Fabric requires 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


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  
---|---  
Release Date | Description | Patch/Build | Mule Runtime | Runtime Manager/Maven/API Tag for New Deployment  
Oct 3, 2023 | First release of 4.5.0 | 0th patch and 1st build | 4.5.0:1e  
Nov 7, 2023 | Second release of 4.5 | 1st patch and 1st build | 4.5.1:1e  
Nov 7, 2023 | Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric | 1st patch and 2nd build | Not Available | 4.5.1:2e  
Nov 7, 2023 | OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric | 1st patch and 3rd build | Not Available | 4.5.1:3e  
Dec 5, 2023 | Second patch version of 4.5 | 2nd patch and 1st build | 4.5.2:1e  
Jan 2, 2024 | Hot fix for a Mule runtime regression | 3rd patch & 1st build | 4.5.3:1e  
Feb 6, 2024 | Release of new minor | 0th patch and 1st build | 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.


After you select the option **Use Edge Release Channel** in the Runtime Manager UI, the platform shows all the build tags for Edge and LTS channels. The build tag is specific to Runtime Manager and CloudHub 2.0 because the image can be built multiple times for a given Mule runtime version. The Runtime Manager UI does not show build tags for Mule runtime engine versions < 4.5 but you can still use any build through the API.
## See Also
  * Runtime Fabric Runtimes Release Notes