Fix GH-8038: DOM extension reflection version is incorrect

[cmb69]

It doesn't appear to be reasonable to pretend that nothing in the DOM API would have changed in the last 21 years, and it's also not that reasonable to pretend that we would thoroughly bump that version in the future. Thus we go with the common convention to use the PHP_VERSION for bundled extensions.

---

It might also make sense to rename to PHP_DOM_VERSION or something.

[nielsdos]

I considered this at one point, but I don't know how this will interact with composer.json requirements. If you look for 20031129 in GitHub you can see hits of the form ext-dom: "20031129". If we change the version to 8.5, how will that affect them? 8.5<20031129 so I suppose this will give problems?

[cmb69]

If you look for 20031129 in GitHub you can see hits of the form ext-dom: "20031129".

Oh, I have not thought about this. However, if you can't untangle the knot, use brute force.

[TimWolla]

If you look for 20031129 in GitHub you can see hits of the form ext-dom: "20031129"

This specific variant pins to an exact version. To require “any higher version” you would need >=20031129 or similar. See:

{
    "type": "project",
    "require": {
        "php": "8.1.*||8.2.*||8.3.*||8.4.*",
        "ext-dom": "20031128"
    },
    "config": {
        "platform": {
            "php": "8.1.99"
        }
    }
}

(note the 28 instead of 29 at the end):

No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires PHP extension ext-dom 20031128 (exact version match: 20031128, 20031128.0, 20031128.0.0 or 20031128.0.0.0) but it has the wrong version installed (20031129).

[cmb69]

The question is also whether these have been results of composer.json or composer.lock.