Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125413
Precedence: bulk
MIME-Version: 1.0
References: <bbe97adb-4d31-4f38-833e-f0c65c0dbcc4@gmx.de>
In-Reply-To: <bbe97adb-4d31-4f38-833e-f0c65c0dbcc4@gmx.de>
Date: Wed, 4 Sep 2024 21:04:15 +0700
Message-ID: <CANLbj-p3Gv7FOC1f7riG2W=7ty5e2w9qmw9uZ=zOeyNdt=bx3Q@mail.gmail.com>
Subject: Re: [PHP-DEV] Where to document configuration option changes?
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
From: ayesh@php.watch (Ayesh Karunaratne)

> 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.