How long a release is supported

Read this alongside the compatibility article: the deprecation periods and the backward window there are the parts of a support lifecycle that are already written down.

What is committed today

• A backward window of N-1. At any time the current major and the one immediately before it are supported, and a reader that supports the next version must keep accepting the previous one.

• A longer commitment for the 1.0 line. TOVIO 1.0's storage format, wire protocol, and capability-token schema are supported for a minimum of 24 months from the 1.0 release date, independent of later major releases.

• Minimum deprecation periods per surface class — 12 months for the storage format, the conformance corpus, the crypto domain-separation constants, the Forge operational records and the audit records; 12 months for the wire protocol, the agent API and request proof; 12 months for capability tokens and the plugin contract; and 6 months for the command surface, Forge routes, and the native bindings. Both versions stay supported throughout, with a migration notice naming the replacement and the earliest release that may remove it.

What a supported release receives

• Security fixes.

• Correctness fixes for defects that risk data loss or incorrect permission enforcement.

New features land on the current line, not on older ones.

Security fixes come first

A vulnerability in the cryptography or the permission enforcement is the highest-priority work in the project. A change required to fix a security defect may take an accelerated path through the deprecation policy — but it still ships a migration, is disclosed under the security policy, and records the shortened window and its justification in the release notes. Shortening a window is a documented event, not a quiet one.

Staying supported

Track the current line, and read the changelog before upgrading. It is the system of record: breaking changes appear there under their own heading, naming the version they land in, the version they deprecate, and when the window closes. Pin a version in continuous integration so a release cannot arrive mid-pipeline.

Check each release's rollback boundary too — the oldest release it can be downgraded to without data loss, and the features that, once used, prevent a downgrade. That list is what turns an upgrade from a one-way door into a decision you can reverse.

Platform floors move under the same rule

Dropping a target or raising a minimum operating-system version is a breaking change and is announced as one, with the same deprecation period. Note that every declared target currently carries a certification flag that is not yet set: the floors are declared, not verified.

What is not yet published

There is no published support lifecycle for a release line, because no release has been accepted or tagged. Everything above is a commitment recorded in the compatibility policy — which is itself still a Draft document — rather than a window already running. Treat a specific end-of-support date as something to ask for, not something to assume.

If you need a longer window

Extended support is a commercial conversation rather than a published policy. Ask rather than assuming a window exists.