Seven documented extensions are backed by PECL packages that have seen no release in 4 to 10 years, yet the manual does not clearly signal this to readers. Their reference pages are otherwise complete, so someone landing on them has no easy way to tell the extension is effectively abandoned.
This is a triage proposal, not a removal request: the goal is first to agree on surfacing the maintenance status, then to discuss per extension whether to keep-and-mark or archive. Any actual removal is a Doc Group / mailing-list decision.
| Extension |
Latest PECL release |
Manual pages |
&warn.experimental; today |
Notes |
| gmagick |
2.0.6RC1 (2021-02) |
191 |
yes |
never had a stable release |
| xmlrpc |
1.0.0RC3 (2021-12) |
19 |
yes |
unbundled + deprecated in PHP 8.0; PECL page says "not maintained anymore and has been superseded" |
| svn |
2.0.3 (2019-12) |
54 |
yes |
PECL package declares PHP <= 8.0 |
| mqseries |
0.15.0 (2017-07) |
22 |
yes |
|
| geoip |
1.1.1 (2016-08) |
25 |
no |
depends on MaxMind legacy libGeoIP, EOL since 2019 |
| zmq |
1.1.3 (2016-02) |
48 |
no top-level banner |
PECL page says "This package is not maintained" |
| radius |
1.4.0b1 (2016-02) |
35 |
no |
only &warn.experimental.func; on functions, no top-level banner |
None of the pages carry an "unmaintained / no release since YYYY" note, which is the concrete gap.
Proposed first step: add a short maintenance-status note (unmaintained, last PECL release date) to each extension's intro page, reusing the existing warning-note style. Whether any of these should then be moved out of the active manual is left open for discussion here and, if there is appetite, on the phpdoc list.
Release dates are from the PECL package pages. Runtime behaviour on PHP 8.4 was not build-tested for this triage; svn is noted separately because its PECL package itself caps at PHP 8.0.
Seven documented extensions are backed by PECL packages that have seen no release in 4 to 10 years, yet the manual does not clearly signal this to readers. Their reference pages are otherwise complete, so someone landing on them has no easy way to tell the extension is effectively abandoned.
This is a triage proposal, not a removal request: the goal is first to agree on surfacing the maintenance status, then to discuss per extension whether to keep-and-mark or archive. Any actual removal is a Doc Group / mailing-list decision.
&warn.experimental;today&warn.experimental.func;on functions, no top-level bannerNone of the pages carry an "unmaintained / no release since YYYY" note, which is the concrete gap.
Proposed first step: add a short maintenance-status note (unmaintained, last PECL release date) to each extension's intro page, reusing the existing warning-note style. Whether any of these should then be moved out of the active manual is left open for discussion here and, if there is appetite, on the phpdoc list.
Release dates are from the PECL package pages. Runtime behaviour on PHP 8.4 was not build-tested for this triage; svn is noted separately because its PECL package itself caps at PHP 8.0.