Support Lifecycle & Deprecation Policy

How long a release is supported, and how features and contracts are deprecated, so you can plan upgrades with confidence.

Release support lifecycle

Current GA release — fully supported, receives fixes and security updates.
Previous MINOR releases within the current MAJOR line — supported for a defined window after a newer minor ships, to give you time to upgrade.
Previous MAJOR line — supported for a transition window after a new MAJOR ships.

Specific support windows and end-of-support dates for a given release are published in that release's notes and confirmed in your support agreement. Contact support@specaria.io for the authoritative lifecycle dates for your deployment.

What "supported" means

| 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 principles

The product treats anything that crosses a process boundary or persists across deploys as a contract that deserves a deprecation path, including:

public API payload fields and endpoints,
error codes,
configuration keys / environment variables read by more than one component,
the license contract,
database identifiers consumers may depend on.

When one of these is deprecated:

Announce in the release notes of the release that introduces the deprecation, with the reason and the recommended replacement.
Keep working through at least the remainder of the current MAJOR line, unless a security issue forces a faster timeline (which is called out explicitly).
Warn at runtime where practical (for example, a deprecation log line) so operators see it before it's removed.
Remove only in a subsequent MAJOR release, listed in that release's breaking-change section.

Mappings and generated contracts

Per-service mapping versions and generated contracts (OpenAPI v3 / WSDL) are not subject to product deprecation timelines — they are under your control:

Mapping versions are immutable; you decide when to activate or roll back.
A change you intend for consumers should be published as a new mapping version (and, where you version your public path, exposed under a new path), so existing consumers are never broken by a platform upgrade.

This separation means a product upgrade never deprecates one of your published API contracts — only Specaria-owned contracts (APIs, error codes, config keys, license format) follow this policy.

Scope changes (features moving in or out)

Capabilities currently outside the standard product (listed under "Known limitations" in the v1.0 GA notes) may be added to the standard product in a future release, or remain bespoke-engagement features. Any such change is announced in release notes. Items on the roadmap (VM images, AWS/Azure/Oracle native ports, additional IdPs, dedicated modern-gateway connectors) are directional until they ship and appear in a release.

All Specaria SOAP to REST docs

Loading…