[pkg-php-pear] Bug#976811: transition: php8.0

[David Prévot]

Hi,

Le Fri, Dec 11, 2020 at 12:38:01PM -0400, David Prévot a écrit :
> Le Tue, Dec 08, 2020 at 09:28:38AM +0100, Ondřej Surý a écrit :
> 
> > I would like to transition the PHP to version 8.0;
> 
> The timing of this request makes me uneasy […]
> 
> > it's not such a huge bump as it was with 5.6 -> 7.0 and
> 
> [ 7.3 -> 7.4 was not a huge bump but took months to deal with ]

A look at https://php.watch/versions/8.0 (just the size of the page,
compared to https://php.watch/versions/7.4) and a few pages linked from
there helps me disagree to your “not such a huge bump”.

> > most of the packages that were compatible with PHP
> > 7.4 are working just fine with PHP 8.0.
> 
> That does not match my experience as a maintainer of about a hundred
> packages relying on PHP. Many upstream are currently releasing updates
> to fix compatibility with PHP 8.0, and many more have not yet done so.
[…]
> uploading [PHPUnit from experimenatal] to unstable would mean
> having to deal with dozens of breakage (in the FTBFS form):
> 
> https://release.debian.org/britney/pseudo-excuses-experimental.html#phpunit

I spent my weekend on this list, uploaded about twenty packages that can
now at least pass their test suite with PHPUnit 8 or 9, under PHP 7 or
8, so the list is about half the size it was two days ago. I managed to
deal with some (easy) PHP 8 issues, but I’m stuck on a dozen of the
remaining packages: I’ve updated their repository, but didn’t upload
them yet (because it only fixes the PHPUnit issues, not the PHP 8 ones).

My point of view after actually working on those issues is that there is
a significant number of packages that are not working just fine with PHP
8.0, and require a fair amount of work before that. Some of them being
security sensitive, so just working around visible issues may not be of
the best interest of anyone…

> That said, it would be nice to have an updated php-default in
> *experimental* to help have a grasp of the possible breakages.

Thank you for your quick upload! As expected, the number of packages
failing on CI is significant (a lot more than the PHPUnit related ones),
and may I stress that it only shows packages that do run autopkgtests,
so we are probably missing a lot (and it may take some time to catch
them).

https://release.debian.org/britney/pseudo-excuses-experimental.html#php-defaults

I hear the argument about PHP release schedule, but this schedule is not
new (there is a lot we could have done to prepare for such a huge bump
if you had shared your plans in advance), and the PHP 7.2 to 7.3 update
before Buster freeze was really nothing compared to this PHP 7.4 to 8.0
update.

Don’t get me wrong, I love how PHP 8.0 is way faster in my environment,
but I’m really concerned about the compatibility of the code running on
it (not only as Debian packages, but also as installed by our users).

Regards

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-php-pear/attachments/20201213/bc8712f9/attachment-0001.sig>