Hi all,
recently, I've stumbled upon an older bug report which claimed that the
version of ext/dom would be incorrect[1]. Since this still is reported
as "20031129" (!), I submitted a PR[2] to update that according to the
usual convention that bundled extensions report the same version as PHP
(e.g. "8.5.0-dev"). However, Niels was concerned that this could break
consumers, since the new version would be less than the old version. I
followed up with a change to use the stringified ZEND_MODULE_API_NO
(e.g. "20240925"). While that would solve the version
"incompatibility", it seems that some code (e.g. composer.json) relies
on the exact "20031129" version (no wonder, since this is stable for
more than 20 years).
Now the question is, if we want to update the version number, and which
scheme we want to use. Is it nobler to bow to the historic mistake not
to update the version earlier (and stick with a completely useless DOM
version), or to possibly break existing consumers (for the sake of
offering a somewhat meaningful ext/dom version in the future)?
In hindsight, going to ZEND_MODULE_API_NO would not make sense at all;
while that might reduce BC breakage, it still is not meaningful, since
that is already catered to by not being able to load extensions with a
different ZEND_MODULE_API_NO. Using PHP_VERSION, on the other hand,
might allow consumers to require e.g. PHP 8.5.*, but to still require
ext/dom ~8.5.7, for instance.
Currently, I tend to prefer to update to PHP_VERSION, possibly delaying
that to PHP 9, where a break might be more acceptable. I'm looking
forward to hear about your opinion.
[1] https://github.com/php/php-src/issues/8038
[2] https://github.com/php/php-src/pull/17702
Christoph