# Versioning and release management

Ripple Custody supports versioning so that integrators can roll out changes over time. This section explains how the platform and APIs are affected by versions and how to use those versions in your requests.

Ripple Custody versions are made up of three numbers, in the following format: **MAJOR**.**MINOR**.**PATCH**.
For each new release, one of the numbers is incremented, depending on the type and scale of the release.

### Application versions

The following table summarizes how the three different release types are categorized for applications.

| Type | Description | Intended frequency |
|  --- | --- | --- |
| **MAJOR** | Major change in the product, either in infrastructure or API | 2 years |
| **MINOR** | New feature or minor infrastructure change | Every new feature |
| **PATCH** | Patch to fix a security or feature issue, to keep system security and functionality optimal. Total upward compatibility is guaranteed. | As needed |


### API versions

In our API, we apply a principle of small and frequent releases, allowing us to ensure the security of our application. It is also an important asset for monitoring the evolution of blockchain networks.

The following table summarizes how the three different release types are categorized for APIs.

| Type | Description | Validity period |
|  --- | --- | --- |
| **MAJOR** | Only relates to the major version of the calling interface. We guarantee the stability of authentication mechanisms and object patterns (for example, pagination) in a **MAJOR** version. In the lifecycle of a **MAJOR** version, we allow breaking changes with a notification period of **1 year**. This notification will always be accompanied by an explanation and advice on how to modify your integration. | Once a new **MAJOR** version is released, the **MAJOR-1** version is deprecated within **1 year**. A **MAJOR** version is considered active until it is replaced by a new **MAJOR** version. |
| **MINOR** | A **MINOR** version is considered active until it is replaced by a new **MINOR** version on the same **MAJOR** version. | A minor version can apply to SaaS deployments, with a maintenance phase of 4 weeks, or on-premise deployments, with a maintenance phase of one year. |
| **PATCH** | A **PATCH** version is considered active until it is replaced by a new **PATCH** version on the same **MINOR** version. | Once it is replaced, the old version is no longer under maintenance. We strongly advise you to apply patches as soon as possible. |


You can always find the latest version of the API specification in our [API documentation](/products/custody/reference/api/openapi).

## Release management

Ripple offers Custody products as part of both an on-premise and SaaS deployment model. There are two types of release:

| Release type | Release schedule | Released to | Validity period |
|  --- | --- | --- | --- |
| Long-term support release (LTS) - on-premise | Every 6 months | Ripple container registry | 12 months |
| Short-term support release (STS) - SaaS | Regular, as needed for new features | Ripple Cloud environment | Until next STS release (approximately 4 weeks) |


### On-premise release management

On-premise customers can obtain new LTS release software images from our container registry.

### SaaS release management

SaaS customers receive STS releases automatically in the Ripple Cloud environment. Ripple offers three tiers of environment:

- Integration (INT): For development, testing, and experimenting with the platform.
- User acceptance testing (UAT): A pre-production environment to test changes intended to be pushed to production.
- Production (PROD): For all production operations.


A standard maintenance window exists: between 11:00 and 14:00 UTC. For UAT and PROD, maintenance sessions are only scheduled on Mondays.

Updates happen in order, where INT environments are updated first, as soon as a new release is available. After INT environments are updated, UAT updates are scheduled for the next maintenance window. Following UAT, after an additional week, PROD updates are scheduled.

This schedule is designed to ensure we catch any unexpected issues with new features ahead of the production update. For this reason, for new feature releases, this schedule never changes. However, patch releases, especially for urgent fixes related to security, may be expedited.