Version Policy

Status: Documentation policy baseline. A formal support-lifetime schedule has not yet been published. See Support Lifecycle for the current public status and the complete decision record required before a release line can be called supported or LTS.

TeaQL consists of several versioned parts that must be evaluated together:

• model format and modeling rules;
• generator or client;
• generated Java or Rust code;
• runtime libraries;
• framework integration;
• database or service provider;
• application extension code.

A shared version number must not be assumed to make every combination compatible. Use the Compatibility Matrix and evidence emitted by the selected generator.

Compatibility Terms

Term	Meaning
Documented	A page or release article mentions the combination. It may not have been reproduced by the documentation build.
Tested	A recorded clean generation and build/test run succeeded for the exact combination.
Supported	Maintainers have explicitly committed to handle defects for the combination under a stated policy.
Deprecated	Still available for a transition period, but new usage should move to the documented replacement.
Removed	No longer available in the stated release line.

Only maintainers can promote a combination from tested to supported.

Compatibility Expectations

Patch-Level Changes

Patch-level releases should avoid intentional generated API or configuration breakage. Users must still review regenerated output, dependency changes, and provider behavior.

Feature-Level Changes

Feature releases may add generated methods, runtime capabilities, providers, or configuration. They may also deprecate older surfaces. Migration notes are required when handwritten code or operations must change.

Breaking Changes

Any release that requires one of the following must be treated as breaking, regardless of the version string:

• generated method renames or removals;
• changed query or mutation intent requirements;
• generator/runtime incompatibility;
• changed configuration names, defaults, or precedence;
• provider removal or transaction-semantic changes;
• Java/Rust toolchain baseline changes;
• destructive schema behavior;
• audit, authorization, tenancy, or masking behavior changes.

Generated-Code Policy

Generated output is a compatibility surface even when users do not edit it. Release notes must identify changes that can affect handwritten callers:

• entity methods;
• Q request methods;
• selection and relationship APIs;
• mutation and audit chains;
• generated module or package layout;
• dependency and feature sets;
• schema metadata.

Regeneration diffs are required upgrade evidence. Users must fix models, configuration, generator versions, or handwritten callers rather than patching generated source.

Support-Lifetime Gap

The current public documentation does not define:

• long-term-support release lines;
• maintenance duration;
• security-fix backport policy;
• end-of-life notification period;
• supported combinations for every Java, Rust, framework, and provider version.

Until those commitments are published, do not infer them from artifact availability or historical blog posts. The documentation currently follows the latest verified baseline; this is a documentation-maintenance scope, not a product support duration or security-backport promise.

Release Requirements

A release that changes public or generated behavior should publish:

1. component versions;
2. compatibility baseline;
3. added, changed, deprecated, and removed behavior;
4. generated API impact;
5. configuration and environment impact;
6. schema/provider impact;
7. migration and rollback guidance;
8. verification commands;
9. known limitations.

See Upgrade Guide for the operational path.