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
