The compatibility registry is not just a list of labels. It decides which runtime variants are shown first, which legacy variants are hidden behind warning blocks, how PHP is selected from Joomla lines, and how minimum database versions are emitted into Joomla update XML.
Статусы жизненного цикла
| Area | Statuses | Meaning |
|---|---|---|
| Joomla | Supported, EOL, Future | Product target line. EOL should remain available for historical releases but warned. |
| PHP | Supported, Security only, EOL, Future | Runtime lifecycle. Security-only lines may still work but should be treated as legacy-варианты. |
| Database | Supported, Extended support, EOL, Future, Inactive | Database vendors often use mainstream/extended lifecycle rather than PHP-style security-only labels. |
Joomla to PHP matrix
Each Joomla line can declare minimum, maximum and recommended PHP versions. The release form uses those rules to preselect PHP when Joomla-линий are toggled. Removing a Joomla line recalculates the PHP selection so stale runtime support does not remain checked by accident.
Database minimum versions
For each database engine, releases can select one minimum product line. Not declared means the generated update XML will not contain a supported_databases rule for that engine. This is cleaner than inventing a fake minimum when the extension does not have database-specific requirements.
- Use product lines such as SQL Server 2022 / 16.x instead of build numbers like 16.0.1000.6.
- Keep latest supported versions first in admin lists and public choices.
- Place EOL and inactive lines behind блоки предупреждений in release forms.
Manual order and sorting
Manual order exists because not every lifecycle can be sorted alphabetically or numerically. The registry should show the latest practical versions first, while AJAX filters help operators find old lines without scrolling through long lists.