Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110384
MIME-Version: 1.0
References: <CAF+90c_TqgaY_srwX5w1EtqKRnR91_KebOp1cqyqrdvghrNGpg@mail.gmail.com>
In-Reply-To: <CAF+90c_TqgaY_srwX5w1EtqKRnR91_KebOp1cqyqrdvghrNGpg@mail.gmail.com>
Date: Fri, 5 Jun 2020 11:14:37 +0200
Message-ID: <CAOWwgp=O7d52_ks6N5s03O0DQGsmMNFURGWd8v4qpQbL+YkcAA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000066ee7205a752b14e"
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--00000000000066ee7205a752b14e
Content-Type: text/plain; charset="UTF-8"

> 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

--00000000000066ee7205a752b14e--