Support Lifecycle and Deprecation Policy

Learn about the support lifecycle for product releases and the policy for deprecating APIs, configuration, and other platform contracts to plan upgrades.

Overview

This document outlines the support lifecycle for product releases and the formal policy for deprecating platform features and contracts. The policy is designed to provide predictability for API publishers and platform operators, enabling confident planning for upgrades and maintenance.

It defines:

The support duration for different release versions (major and minor).
The level of support provided for each release category (e.g., bug fixes, security patches).
A clear, multi-step process for deprecating and removing platform contracts such as API endpoints, configuration keys, and error codes.
The distinction between platform-managed contracts and user-managed contracts (e.g., API mappings).

Understanding this policy is essential for managing your integration with the platform and ensuring smooth transitions between versions.

Release Support Lifecycle

The platform provides support for releases according to their version and age. The lifecycle is divided into several stages, ensuring that API consumers have adequate time to upgrade from older releases.

flowchart TD
    subgraph Major Release Cycle
        A[Current GA Release] -- New Minor Release --> B[Previous Minor Release];
        A -- New Major Release --> C[Previous Major Line];
    end

    subgraph Support Status
        B -- Support Window Ends --> D[Out of Support];
        C -- Transition Window Ends --> D;
    end

    style A fill:#d4fada
    style B fill:#fef3cd
    style C fill:#fef3cd
    style D fill:#f8d7da

The primary release categories are:

Current GA release: The latest, generally available version of the product. It is fully supported.
Previous MINOR releases within the current MAJOR line: These releases remain supported for a defined window after a new minor version is released, providing time to plan and execute an upgrade.
Previous MAJOR line: The entire previous major version line is supported for a transition window after a new major version is released.

NOTE

Specific support windows and end-of-support dates for any given release are published in that release's notes and confirmed in your support agreement. Contact your designated support channel for the authoritative lifecycle dates for your deployment.

Support Levels

The term "supported" encompasses different levels of maintenance depending on the release's lifecycle stage.

Aspect	Current GA	Previous minor (in window)	Out of support
Security fixes	Yes	Yes	No
Bug fixes	Yes	Critical only	No
New features	Yes	No	No
Documentation	Yes	Maintained	Archived

Deprecation Policy

The platform treats any component that crosses a process boundary or persists across deploys as a contract that requires a managed deprecation path. This policy applies to platform-owned contracts, not user-defined API contracts.

Deprecated Contracts

The following types of platform-owned components are considered contracts and are subject to this deprecation policy:

Public API payload fields and endpoints
Error codes
Configuration keys and environment variables read by more than one component
The license contract
Database identifiers that consumers may depend on

Deprecation Process

When a platform contract is scheduled for removal, it follows a four-step process:

Announce: The deprecation is announced in the release notes of the version that introduces it. The announcement includes the reason for the deprecation and the recommended replacement.
Keep working: The deprecated feature continues to function through at least the remainder of the current MAJOR release line.
Warn: Where practical, the platform will issue runtime warnings (e.g., a log line) when a deprecated feature is used. This helps operators identify usage before the feature is removed.
Remove: The feature is removed only in a subsequent MAJOR release. The removal is documented in that release's breaking-change section.

WARNING

A critical security issue may force an accelerated deprecation and removal timeline. Any such exception will be explicitly announced and justified.

Contracts Not Covered by This Policy

This deprecation policy does not apply to contracts that are under the API publisher's control.

Mapping versions: These are immutable. The API publisher decides when to activate a new version or roll back to a previous one.
Generated contracts (OpenAPI v3 / WSDL): These are derived from your mappings.

IMPORTANT

A platform upgrade will never deprecate one of your published API contracts. Changes intended for your API consumers should be published as a new mapping version and, if applicable, exposed under a new versioned public path. This practice ensures that existing consumers are not broken by platform or API changes.

Scope Changes

Platform capabilities may evolve over time. Features currently listed under "Known limitations" may be incorporated into the standard product in a future release. Any such change is announced in the corresponding release notes.

Roadmap items, such as support for new VM images, cloud provider-native ports (AWS, Azure, Oracle), additional IdPs, or dedicated gateway connectors, are directional until they are officially shipped and documented in a release.