> In my opinion these changes should be documented in UPGRADING, but not > in UPGRADING.INTERNALS, because they are relevant for users who build > PHP themselves, packagers (aka distro managers) and the documentation > team, and neither of these is supposed to read UPGRADING.INTERNALS. And > I believe that it has been done this way in the past. > > What do you think? >
I agree with you, that `./configure` option changes should ideally be listed in the `UPGRADING` file. For packagers, I would imagine they now have to lookup both UPGRADING (INI changes, underlying libraries such as libcurl-dev minimum version bumps, alternative PCRE2 versions, etc) as well as the `UPGRADING.INTERNALS` for `./configure` flags. Apart from the "Build system changes" section, the rest of the UPGRADING.INTERNALS file is only useful when developing PHP extensions or php-src itself. If we were to move the Build System Changes to the UPGRADING file, all "user" and "packager" facing changes are listed in the UPGRADING file, Change log in the NEWS file, and PECL/php-src related changes in the UPGRADING.INTERNALS file.
