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.
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 |
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.
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 customers can obtain new LTS release software images from our container registry.
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.