Support Lifecycle
Current public status: TeaQL documentation follows the latest verified component versions. TeaQL has not yet published a complete product-support lifecycle with maintenance durations, LTS lines, security backport windows, or end-of-life dates.
This page makes that gap explicit. It does not turn artifact availability, source presence, a successful test, or an older release article into a support commitment.
What “Latest” Means Today
The maintained documentation baseline is the set of component versions listed on Latest Versions. The baseline is refreshed from the official version and artifact sources and then checked against current examples and compatibility evidence.
“Latest” means:
- the version currently selected for maintained documentation;
- the first target for new documentation fixes and verification;
- the version that operational commands and dependency examples should use.
It does not mean:
- every latest component is compatible with every other component;
- every advertised generator target or provider has passed a clean build;
- older releases receive fixes or security backports;
- the latest release has a guaranteed maintenance duration or response time.
Use the Compatibility Matrix to distinguish discovered, generated, tested, blocked, and supported evidence.
Current Lifecycle Commitments
| Question | Current public answer |
|---|---|
| Which release line is maintained by these docs? | The latest verified baseline. |
| Are older release lines maintained? | No public commitment is documented. Treat their material as historical unless a release-specific policy says otherwise. |
| Is there an LTS release? | No public LTS designation is documented. |
| How long are fixes provided? | No maintenance duration is documented. |
| Are security fixes backported? | No backport policy is documented. |
| How much EOL notice is provided? | No notification period is documented. |
| Which combinations are supported? | Only combinations explicitly promoted by maintainers may be called supported. Current pages primarily record documented, observed, tested, or blocked evidence. |
| Is artifact retention a support signal? | No. A downloadable artifact may be retained for reproducibility without remaining supported. |
Choosing a Version Before a Formal Policy Exists
For a new project:
- Start from Latest Versions.
- Select the Java or Rust path in the Compatibility Matrix.
- Confirm the exact generator, runtime, framework, provider, database, and toolchain combination has enough evidence for the project.
- Run the Upgrade Guide verification steps in the project's own environment.
- Record the selected versions and retained evidence with the application.
For a project pinned to an older release, do not infer continued maintenance from an available package. Keep the exact generator and runtime versions, preserve a reproducible build, review the applicable historical migration material, and qualify an upgrade to the current baseline.
Evidence Is Not Support
| State | What it proves | What it does not prove |
|---|---|---|
| Available | An artifact or source path can be found. | Compatibility, correctness, or future fixes. |
| Documented | A maintained or historical page describes it. | Successful reproduction. |
| Tested | The recorded combination passed the stated checks on a stated date. | A support duration, SLA, or backport commitment. |
| Supported | Maintainers explicitly commit to a scope and time window. | Compatibility outside the named scope. |
| LTS | Maintainers publish a longer, named support window. | Indefinite maintenance. |
| EOL | The published support window has ended. | Artifact deletion. |
The current compatibility pages must continue to use tested or a narrower
evidence label until maintainers publish the scope and duration needed for
supported.
Required Support-Policy Decision
Before a release line is labeled supported or LTS, maintainers must publish all of the following:
- release line and included component versions;
- support start date and end date;
- maintenance and security-fix scope;
- whether fixes are backported or require an upgrade;
- supported Java/Rust toolchains, frameworks, providers, and databases;
- severity or eligibility rules for fixes;
- EOL notification channel and minimum notice period;
- upgrade and rollback path;
- evidence location and accountable owner;
- exceptions, exclusions, and superseding policy.
A release entry should use this minimum record:
| Field | Required value |
|---|---|
| Release line | Named version or bounded version range. |
| Lifecycle state | Supported, LTS, deprecated, or EOL. |
| Effective dates | Start, maintenance end, and security end where different. |
| Compatibility scope | Exact generator/runtime/toolchain/framework/provider boundaries. |
| Fix policy | Eligible fixes and delivery/backport rule. |
| Notice policy | Announcement location and minimum notice. |
| Migration | Upgrade guide, breaking changes, and rollback boundary. |
| Owner | Maintainer role responsible for decisions and updates. |
Leaving a required field blank keeps the entry provisional; it must not be presented as a support promise.
Release and Documentation Updates
When maintainers approve a lifecycle decision, update these pages together:
- this lifecycle page;
- Version Policy;
- Compatibility Matrix;
- Changelog;
- Release Notes;
- affected migration and upgrade pages.
Record the decision date separately from artifact publication and verification dates. If a commitment changes, retain the previous dates as history and state the effective date of the replacement policy.