Deprecation Policy
Purpose
This policy defines how Avassa Systems communicates and executes deprecations and planned non-backwards compatible changes of customer‑facing interfaces, including the REST API, the supctl CLI, and the Volga WebSocket API. Our goal is to give customers sufficient time and guidance to update integrations while allowing the Avassa platform to evolve responsibly.
Scope
The policy covers any non-backwards compatible changes to a publicly supported interface that could cause existing customer workloads, scripts, or automations to fail. Typical examples include:
- Removing a field or endpoint
- Renaming fields, endpoints, CLI commands, or WebSocket events
- Making a previously optional field mandatory
- Changing a response data type in a non‑compatible way Backward‑compatible changes (e.g. adding new optional fields) are not subject to this policy.
Definitions
| Term | Meaning |
|---|---|
| Backward compatible change | A modification that does not require customers to update their code. Existing calls continue to succeed without alteration. |
| Non-backward compatible change | A modification that can require modification of customer integrations or code to work as expected. |
| Deprecation notice | The formal communication that a feature or behavior is scheduled for removal or modification. |
| Deprecation period | The time window between the deprecation notice and the enforcement of the non-backwards compatible change |
Deprecation Process
Avassa provides at least 60 days’ notice to minimize disruption before enforcing non-backwards compatible changes (unless an exception is explicitly stated). During this period:
- The deprecated feature will continue to function as before
- Users are expected to update any scripts, integrations, or client code accordingly
- After the 60-day window, the deprecated feature may be removed without further support.
| Phase | Description | Typical Duration |
|---|---|---|
| Identification | Avassa engineering determines that a non-backwards compatible change is necessary. | – |
| Announcement | Official deprecation notice is published (Day 0). | Immediate |
| Transition period | Deprecated feature continues to function. Customers migrate. | Day 0 – Day 59 |
| Removal / Enforcement | Feature is removed or altered. Post‑removal support is not guaranteed. | ≥ Day 60 |
Deprecation Notice Contents
A deprecation notice is our formal announcement of a planned change. It includes:
- Description – What is changing and why.
- Affected Interface(s) – API endpoints, CLI commands, schemas, or WebSocket topics.
- Migration Guidance – How to update code or configuration.
Announcement Channels
All deprecation notices will be:
- Posted to Deprecation Notices
- Emailed to customers with support accounts
Exceptions
Avassa reserves the right to shorten or bypass the 60‑day period under exceptional circumstances, including:
- Critical security vulnerabilities
- Legal or regulatory compliance
- Changes required to maintain platform stability or data integrity
When exceptions occur, Avassa will communicate as early and clearly as possible, specifying the shortened timeline and rationale.