@MarkRS-UK please have a look at the code style errors and fix them.

Thank you for your contribution. Could you please check your development/Git setup? It’s currently almost impossible to review this PR because entire files appear to have been replaced, probably due to tab or CRLF issues.

I have tested this item 🔴 unsuccessfully on 6be3675

I have tested this item 🔴 unsuccessfully on 6be3675

I have tested this item 🔴 unsuccessfully on 6be3675

Verdict: Needs one small change — the feature works, but it introduces a PHP warning on a
realistic failure path.

The pr does what it claims: the extension changelog modal (System → Manage → Extensions →
click the version) now lists all changelog versions instead of only the installed one, each
under its own version header. Confirmed working. There is one regression to fix before merge, plus a
couple of optional notes.

Verification

Tested on a clean 6.2-dev build of this PR (DDEV, PHP 8.3). Seeded an extension (com_banners) with
a changelog XML containing three versions (3.0.0 / 2.0.0 / 1.0.0, mixed change types) and exercised
the real code path (Changelog::loadFromXml → ManageModel::loadChangelog → FileLayout joomla.installer.changelog).

• After (this PR): all three versions render, each with its <div id="<version>" class="changelog"> header and the correct per-type badges (security/fix/addition/change/remove/
  note) and items.
• Before (base 6.2-dev, per the diff): only the entry whose version matched the installed
  version was kept ($latest), so a single version was shown. The behaviour change is real and
  correct.
• Scope is sensible (4 files, +81/−90); the now-unused deprecated Changelog::get() calls are
  removed from ManageModel and the matching phpstan-baseline.neon entries are correctly dropped.

Finding (needs change) — PHP warning when the changelog is empty or the URL fails

Changelog::$changes is declared public $changes; with no default, and
ManageModel::loadChangelog() iterates it unconditionally:

foreach ($changelog->changes as $key => $entry) {   // ManageModel.php

If loadFromXml() returns no <changelog> entries (empty <changelogs>) or fails entirely
(URL 404 / changelog server unreachable), $changes stays null, so this becomes
foreach (null …):

Warning: foreach() argument must be of type array|object, null given

I reproduced both cases at runtime (empty <changelogs/> → loadFromXml=true, changes=NULL; bad
URL 404 → loadFromXml=false, changes=NULL); both fire the warning (confirmed via CLI with full
error reporting). The old code degraded silently here (it guarded on isset($this->latest) /
get() returned null). A down/missing changelog server is a plausible real-world condition.

Real-world visibility: in the running backend the warning does not surface in the modal —
I tested the actual manage.loadChangelogRaw endpoint with Error Reporting at both default and
maximum, and in both cases the modal is simply empty (0 bytes); Joomla's runtime error handler
keeps the E_WARNING out of the output (it goes to the log). So the user-facing symptom is a silent
empty modal rather than a graceful no-op, and the unguarded foreach over a nullable property is a
code-level regression worth fixing regardless.

Suggested fix

Initialise the property to an array — one line, fixes both cases:

// libraries/src/Changelog/Changelog.php
public $changes = [];

(Optionally also guard in the model: if (empty($changelog->changes)) { return ''; }.)

Optional notes

• Dead code: with the version-match logic gone, setVersion() / $matchVersion (and
  getVersion()) no longer affect anything — ManageModel still calls setVersion() but it is now
  a no-op. Consider removing, or leave for b/c.
• Output escaping: the version key is echoed unescaped into both an attribute and text
  (id="<?php echo $key?>", <span><?php echo $key; ?></span>). It comes from the extension's own
  changelog XML (low risk), but $this->escape() would be more consistent with the project's
  output-escaping stance.
• The author's note (scroll/highlight the installed version via the added id) is not implemented;
  fine for this PR's scope.

Thanks for that. I've implemented all of those. Tested with a valid changelog and with a broken changelog URL which simply yields a blank dialog.

I have tested this item ✅ successfully on 6de5081

I have tested this item ✅ successfully on 6de5081

may i suggest to add something like

   /**
     * Update manifest `<releasedate>` element
     *
     * @var    string
     * @since  __DEPLOY_VERSION__
     */
    protected $releasedate;

to have something like

<changelogs>
    <changelog>
        <element>mod_changelog</element>
        <type>module</type>
        <version>1.0.0</version>
        <releasedate>2024-01-01</releasedate>
        <security>
            <item>Item A</item>
            <item>Item b</item>
        </security>
        <fix>
            <item>Item A</item>
            <item>Item b</item>
        </fix>
        <language>
            <item>Item A</item>
            <item>Item b</item>
        </language>
        <addition>
            <item>Item A</item>
            <item>Item b</item>
        </addition>
        <change>
            <item>Item A</item>
            <item>Item b</item>
        </change>
        <remove>
            <item>Item A</item>
            <item>Item b</item>
        </remove>
        <note>
            <item>Item A</item>
            <item>Item b</item>
        </note>
    </changelog>
    <changelog>
        <element>mod_changelog</element>
        <type>module</type>
        <version>1.1.0</version>
        <releasedate>2026-01-01</releasedate>
        <change>
            <item>Code clean</item>
        </change>
    </changelog>
</changelogs>

Seems like a good idea, but is "releasedate" a valid tag? It's not listed in the documentation.

From that point of view, I'd say this would be out of scope for this PR.

It's not listed in the documentation.

not yet but, all changelogs have that information especially when you are showing all items like in this pr

What is that date then?

Looks to me like it's the creation date, adding "01" if a day isn't specified. Is that meant to signify version release date? That's not what I would have guessed.

version release date