Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111068
MIME-Version: 1.0
References: <CAF+90c_TqgaY_srwX5w1EtqKRnR91_KebOp1cqyqrdvghrNGpg@mail.gmail.com>
 <CAOWwgp=O7d52_ks6N5s03O0DQGsmMNFURGWd8v4qpQbL+YkcAA@mail.gmail.com>
In-Reply-To: <CAOWwgp=O7d52_ks6N5s03O0DQGsmMNFURGWd8v4qpQbL+YkcAA@mail.gmail.com>
Date: Fri, 17 Jul 2020 12:12:19 +0200
Message-ID: <CAF+90c_x6Rv3pHJeb53p1bo=aHcedV-E4x2W_ThLdXCXQbqdPg@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005de6c805aaa065c6"
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000005de6c805aaa065c6
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 5, 2020 at 11:14 AM Nicolas Grekas <nicolas.grekas+php@gmail.com>
wrote:

>
> It's that time of year again. Feature freeze is looming, so it's time to
>> talk about deprecations!
>>
>> https://wiki.php.net/rfc/deprecations_php_8_0
>>
>
> Thanks for the RFC.
> Would it make sense for you to postpone this for 8.1?
> I'm talking with my experience on Symfony here: we decided to give ppl
> some rest when they upgrade and always have our *.0 versions
> deprecations-free.
> Chasing BC breaks is a hard enough task for ppl to upgrade. Adding the
> additional step of solving deprecations is extra work that is not needed
> yet. I know solving deprecations is optional, but many teams have CI that
> fail on deprecations.
>
> I think it could be nicer to the userland community to have a smother path
> here, IMHO.
>
> Nicolas
>

I've retargeted this RFC to PHP 8.1 now. These deprecations are not
time-critical, there has been little discussion of the deprecations
themselves, and we're already in feature freeze induced RFC overload...

Nikita

--0000000000005de6c805aaa065c6--