---
title: "Support matrix"
manual: "TYPO3 LLM Extension"
version: "0.35"
permalink: "https://docs.typo3.org/permalink/netresearch/nr-llm:api-support-matrix@0.35"
source: "Api/SupportMatrix.rst"
modified: "2026-09-16T22:09:16+00:00"
---

# Support matrix

Which TYPO3 and PHP versions nr_llm 1.x runs on, and when each line ends.

## The versions

| TYPO3 | nr_llm 1.x | Regular maintenance ends | ELTS ends |
| --- | --- | --- | --- |
| 13.4 LTS | supported | 2027-12-31 | 2030-12-31 |
| 14.3 LTS | supported | 2029-06-30 | 2032-06-30 |

TYPO3 14.0–14.2 are **not** supported. They are sprint releases, not the
LTS, and the extension requires `^14.3`. The TER `depends` range in
`ext_emconf.php` reads `13.4.0-14.99.99` only because that format
cannot express a gap.

| PHP | nr_llm 1.x | Upstream security support ends |
| --- | --- | --- |
| 8.2 | supported | 2026-12-31 |
| 8.3 | supported | 2027-12-31 |
| 8.4 | supported | 2028-12-31 |
| 8.5 | supported | 2029-12-31 |

## When a line ends

A version stays supported while its upstream is in **regular** maintenance.
ELTS is a paid TYPO3 Association product and nr_llm does not track it.

Dropping a version is a **minor** bump, never a patch, and it happens in the
first minor release after the upstream date above — not on the date itself.
Dropping one raises the floor in `composer.json`, `ext_emconf.php` and
the CI matrix together, and this page moves in the same change.

Further places state the range in prose and are **not** asserted against
anything. The ones known today: the `README.md` badges and its
Requirements list, [Installation](https://docs.typo3.org/permalink/netresearch/nr-llm:installation@0.35), [Introduction](https://docs.typo3.org/permalink/netresearch/nr-llm:introduction@0.35),
`Documentation/Developer/FeatureServices/Index.rst` (its requirements
list), `Documentation/Testing/CiConfiguration.rst` (a hand-copied excerpt
of the CI matrix) and `Documentation/Developer/IntegrationGuide.rst` (the
TER constraint in its `ext_emconf.php` example). A floor change has to
edit them by hand — a green unit suite says nothing about them, and the list
is what has been found, not a proof that nothing else repeats the range.

`BASELINE.md`'s "Multi-version CI" row is the exception: it *is* checked,
by `Tests/Unit/BaselineConsistencyTest`, against the `ci:` job's TYPO3
matrix.

PHP 8.2 is the nearest edge: its upstream security support ends 2026-12-31,
so it is the next floor to rise.

## Declared constraints

The literals below are the ones the build actually uses. They are asserted
against `composer.json`, `ext_emconf.php` and
`.github/workflows/ci.yml` by `Tests/Unit/VersionConsistencyTest` — a
matrix that drifts from what CI runs fails the unit suite rather than
misleading a reader.

-   *composer typo3/cms-core:* `^13.4 || ^14.3`
-   *composer php:* `^8.2`
-   *ext_emconf typo3:* `13.4.0-14.99.99`
-   *ext_emconf php:* `8.2.0-8.99.99`
-   *ci typo3-versions:* `^13.4`, `^14.3`
-   *ci php-versions:* `8.2`, `8.3`, `8.4`, `8.5`

The CI values are the **union** across every matrix in `ci.yml`. Single
cells there — the merge queue's reduced PHP set, the MariaDB functional leg
— are subsets by design and do not narrow what is supported.