A release record is the source of truth for a Joomla update package. It controls what appears on the public release page, what enters the Joomla update XML feed, which package can be downloaded, and which compatibility labels warn installers before deployment.
Release identity
The identity section decides how the release is grouped and whether it is visible or downloadable. The version should match the Joomla manifest version whenever possible; uploaded archives can be inspected to prefill the version when the field is empty.
| Field | Purpose | Operational effect |
|---|---|---|
| Extension | Product or child artifact this release belongs to. | Controls public URL, changelog grouping and update feed ownership. |
| Version | Human and Joomla-facing version identifier. | Used in release pages, changelog URLs and update XML version nodes. |
| Release date | Calendar date shown publicly. | Used for timeline sorting together with semantic version sorting. |
| Stability | Alpha, beta, RC, stable or LTS maturity label. | Warns users but does not block downloads by itself. |
| Channel | Stable, beta, nightly or LTS delivery lane. | Used to separate update streams where channel filtering is enabled. |
| Status | Draft, published, private metadata, yanked or archived. | Controls public visibility, update-feed delivery and download availability. |
Status behavior
- Draft is admin-only and should not appear on public pages or feeds.
- Published is public and downloadable when an artifact exists and the release is not archived.
- Private metadata can show release information to public visitors while blocking package downloads and update-feed delivery.
- Archived keeps history visible but disables package downloads and update delivery.
- Yanked is preserved for admin/history flows and should not be used as normal public delivery.
Release artifact and checksums
The release artifact is stored server-side. Size and checksums are generated from the real file and should be read-only in the form. Manual editing would break trust because the UI could claim a checksum that does not match the stored archive.
| Field | Purpose | Notes |
|---|---|---|
| Upload archive | Stores the release package. | Validates the archive and calculates file size plus MD5/SHA checksums. |
| Download URL | Generated local URL or external artifact URL. | Local uploads should normally generate this automatically. |
| Download type | Joomla downloadurl type: full or upgrade. | Use full for normal extension packages; use upgrade only for intentional update-only packages. |
| Download format | Package format. | Supported uploaded formats: ZIP, TAR, TAR.GZ, TAR.BZ2 and TAR.ZST. In update XML, TAR.GZ is stored as format="gz" and TAR.BZ2 as format="bz2". |
| SHA256/SHA384/SHA512/MD5 | Read-only diagnostic and integrity metadata. | SHA hashes can be copied from the admin form and public release page; MD5 is retained for internal legacy diagnostics. |
| Download variants | Uploaded ZIP/TAR variants and optional fallback URLs. | Uploaded archives become multiple downloadurl rows; fallback URLs are saved as downloadsource rows with type, format, priority and active/inactive status. |
Joomla XML metadata
These optional fields enrich generated update XML. Most releases can leave target dev level empty. Use dev-level limits only when the package is compatible with a narrow Joomla patch/build range.
| Field | Purpose | When to use |
|---|---|---|
| Info URL | Public release information URL. | Use when the release has a canonical public page. |
| Changelog XML URL | Joomla changelog XML endpoint. | Use when Joomla should show structured changelog entries. |
| Maintainer / Maintainer URL | Publisher metadata. | Use for trust and attribution in update XML. |
| Section | Joomla update section metadata. | Usually optional for extension updates. |
| Target min/max dev level | Patch/build-level limits inside a Joomla line. | Leave empty unless you must target only a specific Joomla patch range. |
| downloadsource | Alternative URL emitted after the release downloadurl variants. | Use for mirrors or backup storage; keep the URL on one XML text line. |
Compatibility rules
Joomla versions define the target platform line. PHP versions define runtime support. Database versions generate supported_databases metadata when selected. Warning badges are intentional: they let you document legacy support while making old or extended-support choices visible.
Joomla
Choose one or more Joomla-линий. The system can use the Joomla/PHP compatibility matrix to preselect a practical PHP range.
PHP
For normal extensions, PHP is restricted by the selected Joomla-линий. For language packs, PHP restrictions can be left empty because language packages usually do not execute platform-specific runtime code.
Databases
Choose at most one minimum version per engine. Not declared means no supported_databases XML rule is emitted for that engine.