Asterisk release lifecycle: status, branch docs and module availability

Read status labels and scheduled dates as separate evidence

Treat the official versions table as a dated observation rather than a self-executing calendar. On October 18, 2026, it displayed 23.x as Fully Supported while its Security Fix Only date was October 15, 2026; it displayed 24.x as Pre-release while its release-date cell was October 15, 2026; and it displayed 21.x as Security Fix Only with an end-of-life date of October 18, 2026. Preserve both the displayed label and the scheduled date instead of inventing a transition the page had not yet recorded.

The same snapshot displayed 20.x LTS as Fully Supported with a security-fix-only date of October 19, 2026, and 22.x LTS as Fully Supported with a security-fix-only date of October 16, 2028. Recheck the authoritative table before each decision; do not carry these labels forward as timeless facts.

Distinguish release series, point release and support policy

A release series such as 20.x or 22.x has a lifecycle, while an installed point release identifies the actual code baseline. Asterisk documents Standard releases as receiving one year of bug fixes followed by one year of security fixes, and LTS releases as receiving four years of bug fixes followed by one year of security fixes. Those policy windows do not prove that a specific package repository, appliance or deployment owner currently offers a particular point release.

Record the exact running version, packaging or source owner, selected artifact and the date each fact was observed. The download guidance recommends a supported version and distinguishes the latest LTS choice from the latest feature release, but it does not replace the product vendor or distribution support contract.

Match documentation and API pages to the running branch

A page in the Latest_API tree describes the documentation generator's latest branch, not automatically the installed system. Prefer the exact branch tree when it exists, preserve the page URL and review date, and compare it with the running version before relying on a field, application, function, AMI action, module option or default.

A branch-documentation page proves that the project published documentation for that branch. It does not prove that a downstream package enabled the module, that its dependencies resolved, or that the running process registered the documented capability.

Trace availability from source through runtime capability

Use an explicit chain: feature or module documented for the target branch; source present in the selected artifact; dependencies satisfied; build option selected; module file installed in the active module directory; startup policy permits loading; load succeeds; module status is running where applicable; and the expected CLI command, application, function, channel driver, resource or AMI action is registered.

A module listed by module show like can be loaded yet report Not Running, and a loaded module can still lack an expected capability because configuration, dependencies, branch differences or registration failed. Preserve the first boundary that diverges.

Plan updates and upgrades through the deployment owner

An update within a series and an upgrade to a different major series have different change surfaces. Asterisk notes that major versions can add, change, deprecate or remove functionality and support. Keep source-build, distribution-package, appliance and FreePBX ownership paths distinct, and do not overwrite generated configuration or bypass the supported package workflow to make a documentation example appear.

For a bounded change, preserve the old and new versions, artifact identity, module inventory, configuration owner, generated output, service definition, rollback point and one unaffected control. Rebuild or reinstall all required modules through the same owner so old module binaries are not silently mixed with a new core.

Accept the release only with branch-specific evidence

After deployment, confirm the intended binary is running; compare module inventory and load status; use runtime help or core show help plus application, function and interface inventories; verify one intended workflow; and exercise rollback criteria. Supported-platform guidance warns that an older Asterisk version may stop building after a distribution or compiler upgrade, so capture the platform and toolchain rather than diagnosing the application version alone.

Use the missing feature or module diagnostic when a documented capability is absent. No host, artifact, signature, source tree, package, build, module, configuration, API, endpoint, packet, audio or call was inspected or tested for this guide.

Inventory deprecated functions before a branch transition

The VALID_EXTEN migration guide compares older branch documentation, the current function index and the running CLI without inferring local availability.