Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116152
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1303-gb2406efd75-fm-20210922.002-gb2406efd
Mime-Version: 1.0
Message-ID: <ec7773a1-fff4-4ec0-a9ed-f4c2f298556d@www.fastmail.com>
In-Reply-To: 
 <CAF+90c_JR1mUrgHFkfYYZi2TuSmkaF3hmvT03rfW7kGnhkZf6Q@mail.gmail.com>
References: 
 <CAJp_myX3J8gUb3885KAdEz+xokpZ_mz1Gs_DrN2Tp+JYfewcEw@mail.gmail.com>
 <CAF+90c_JR1mUrgHFkfYYZi2TuSmkaF3hmvT03rfW7kGnhkZf6Q@mail.gmail.com>
Date: Fri, 24 Sep 2021 09:11:36 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] BC breaking changes in PHP 8.1
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Sep 23, 2021, at 11:52 AM, Nikita Popov wrote:

> I believe the changes in PHP 8.1 with the highest migration burden for
> open-source libraries are the additional of tentative return types (aka
> "put #[ReturnTypeWillChange] everywhere") and deprecation of null arguments
> to internal functions, followed by the float to int precision-loss
> deprecation and, depending on project, the Serializable deprecation.
>
> What all of these have in common, is that they are all semver compliant
> changes, because they "only" introduce deprecations. Deprecations are
> explicitly not considered backwards-compatibility breaks.
>
> Now, there are two problems with this picture: The first one is that
> deprecations often get promoted to exceptions by generic error handlers. I
> believe that this continues to be the default behavior of PHPUnit for
> example. This means that in practice, deprecations do break code, even
> though they are intended not to.
>
> The second one is that this does not really hold up for open-source
> libraries. At the application layer, you can suppress all deprecations, and
> call it a day. At the library layer, the usual perception is that if your
> library throws deprecation warnings, it's not compatible with the given
> version of PHP. Taken in conjunction with deprecation to exception
> promotion (in test suites if nothing else) there is some truth to that
> perception.
>
> While deprecations are intended as a backwards-compatible mechanism to warn
> you about upcoming changes without requiring immediate action, in reality
> open-source libraries have to treat deprecations as immediate breakage.

Might one possible way forward be to work with the PHPUnit folks to make deprecations not a test-breaking issue, but report them side-channel somehow?  (Like "risky" tests now pass, but have an extra note on them.)  That seems like it would resolve the "deprecations get turned into breaking changes immediately" problem, at least.

--Larry Garfield