> For the complete documentation index, see [llms.txt](https://knowledgebase.fabricdata.com/fabric-knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledgebase.fabricdata.com/fabric-knowledge-base/support/releases/change-and-release-management.md).

# Change & Release Management

## Change & Release Management

### **1. Change and Release Strategy**

Fabric's change and release strategy includes a monthly release cadence for QA & Live/production environments to ensure the scope of changes is manageable. In situations where a change has the potential to cause disruption to users, Fabric proactively communicates with clients to arrange a suitable release window. Fabric also has detailed rollback plans in place in case of a failed deployment or unexpected issues.

### **2. Hot-fixes**

Hot-fixes may be necessary in the event of a high-priority bug or security vulnerability that requires immediate attention. These fixes can be deployed independently of the scheduled release cadence. The Fabric team will assess the impact and severity of the issue, and communicate with clients regarding the implementation of a hot-fix, if necessary.

### **3. Mandatory and Optional Release**

Fabric's monthly releases operate on an opt-out basis. If a client expresses issues within their QA/Dev Environment, we will not release to their Live environment. All newly developed features in Fabric are on feature toggles, enabling clients to choose whether or not to use them. This approach ensures a shared codebase across client environments without forcing them to utilize/view all features. However, critical security updates necessitate mandatory releases implemented as soon as they become available.

### **4. Versioning Support Policy**

Fabric supports previous versions of the platform. However, we strongly recommend that our users keep their codebase up to date with the latest version, including individual features and components of the platform. This ensures that we can promptly diagnose and resolve any issues that arise and efficiently implement any code updates or feature releases without having to test backwards compatibility for every previous version of the platform.

{% hint style="success" %}
We understand that some users may have specific reasons for staying on older versions of the platform, but we encourage everyone to update to the latest version as soon as possible to take full advantage of the latest improvements and bug fixes. We will provide support for previous versions, but our priority is always to focus on the latest version of the platform to ensure its optimal performance and stability.
{% endhint %}

### **5. Patching** 

Patching is included in the standard release cycle to ensure that the software is secure and free of vulnerabilities. We use Bitbucket Pipelines to automate patch testing and deployment.

***

<details>

<summary>Related Articles</summary>

* [<mark style="color:blue;">Testing Criteria & QA Plan for New Feature Releases</mark>](/fabric-knowledge-base/support/releases/testing-criteria-and-qa-plan-for-new-feature-releases.md)
* [<mark style="color:blue;">Security</mark>](/fabric-knowledge-base/support/security.md)
* [<mark style="color:blue;">Infrastructure</mark>](/fabric-knowledge-base/support/infrastructure.md)

</details>