Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107936
MIME-Version: 1.0
References: <CAH5C8xXnubQv-7CoAR=vjH1qXCmy6omF-8qQktd+QGFvAwQL0Q@mail.gmail.com>
 <bbd5b8c4-31a7-2266-0339-1b2c3a6adbed@gmx.de> <CALKiJKpKFbY1n2bvZdwAQ_dX-p7nm20CJ8yvVxO_eVzJUabF5g@mail.gmail.com>
In-Reply-To: <CALKiJKpKFbY1n2bvZdwAQ_dX-p7nm20CJ8yvVxO_eVzJUabF5g@mail.gmail.com>
Date: Fri, 20 Dec 2019 09:39:15 +0000
Message-ID: <CAPg3XxJFZQgaZ7=zB9a21TM1ZwTXF+fvs6NUOyhMGwHn8S6ToA@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000439f30059a1f75f6"
Subject: Re: [PHP-DEV] Re: Changelog / upgrading notes for promoted warnings
From: petercowburn@gmail.com (Peter Cowburn)

--000000000000439f30059a1f75f6
Content-Type: text/plain; charset="UTF-8"

On Fri, 20 Dec 2019 at 09:31, Rowan Tommins <rowan.collins@gmail.com> wrote:

> On Fri, 20 Dec 2019 at 08:37, Christoph M. Becker <cmbecker69@gmx.de>
> wrote:
>
> > Maybe a sensible compromise would be to assemble a detailed list of
> > these changes, and to hand it over to the doc team at some point, so
> > that the manual pages could (hopefully) be updated in time just before
> > PHP 8.0.0 will be released.  Then users could check the manual's
> > changelog[1] regarding the details.
> >
>
>
> Yes, that sounds reasonable. In many cases, the individual function listing
> should also have a note added at the same time; and at some future date,
> some will be able to lose their "may return false" notes.


This is usually where the UPGRADING document comes in to play. While
watching all of the PRs against master I've very much not been looking
forward
to making sense of all of changes when it comes to updating the PHP manual
to
reflect them.


>
>
> On Fri, 20 Dec 2019 at 00:34, G. P. B. <george.banyard@gmail.com> wrote:
> > Moreover, I'm not sure it's helpful to have a massive list of functions
> where some warnings have been promoted and others not. But this is only my
> opinion
>
> I think this makes it even *more* important to collect the list of changes.
> In the case of password_hash, my understanding is that it will now never
> return false; in other cases, it may still be necessary to check the return
> value. The documentation should clearly state which is the case for each
> function, so we need to keep track of which functions are fully-promoted
> and which partially-promoted.
>

> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

--000000000000439f30059a1f75f6--