PHP 8.0 support
boesing opened this issue · 11 comments
Feature Request
Q | A |
---|---|
New Feature | yes |
Summary
To be prepared for the december release of PHP 8.0, this repository has some additional TODOs to be tested against the new major version.
In order to make this repository compatible, one has to follow these steps:
- Modify
composer.json
to provide support for PHP 8.0 by adding the constraint~8.0.0
- Modify
composer.json
to drop support for PHP less than 7.3 - Modify
composer.json
to implement phpunit 9.3 which supports PHP 7.3+ - Modify
.travis.yml
to ignore platform requirements when installing composer dependencies (simply add--ignore-platform-reqs
toCOMPOSER_ARGS
env variable) - Modify
.travis.yml
to add PHP 8.0 to the matrix (NOTE: Do not allow failures as PHP 8.0 has a feature freeze since 2020-08-04!) - Modify source code in case there are incompatibilities with PHP 8.0
should already part of #166 , @weierophinney said that the PR need to be shrinked with only update php version in composer.json, travis, and remove the float class first.
@samsonasik Thats fine. We can link this issue to the PR so it gets closed on merge.
However, we should remove allow_failures
as PHP 8 is now feature complete and thus, failures should not be allowed at all.
I tried to do that in previous PR for it to make no failure in travis, and its change 156 files, see #164 that closed, and @weierophinney said to shrink the PR, so I shrink it to only update php version in composer.json, travis, and remove the float class.
@samsonasik I probably don't get what you want me to say.
PHP 8.0 upgrade should not require changes in 156 files. I think, that was what Matthew wanted to say...
most changes to make travis green are dependency changes to support, and that requires update code, eg in tests, and I need to shrink that again, and again. I just don't want to spent time more again if it will likely not accepted...
This is to be discussed together with the package deprecation policy that's coming up in the next TSC meeting.
@Ocramius, I've been waiting for #177 to be merged so my application can be PHP 8-compatible, but that PR says it is addressed by this issue... but now this issue is closed apparently without action and I see talk of deprecation of the whole package! Can you direct me to any notes or other information about the future of this package? I have multiple projects that are heavily dependent upon it, so it would be great to know what future plans are so I can adjust accordingly. Thanks!
@demiankatz see https://github.com/laminas/technical-steering-committee/blob/cd3f04cffc65a8490dc730c38dfafb46dd324e44/meetings/minutes/2020-08-03-TSC-Minutes.md#agenda
Work is being done to restore CI runs here, then the package most likely gets ~8.0.0
support, but in order to move it out of security-only, we need an active and committed maintainer for just this package.
Thanks, @Ocramius, that's good to know. Unfortunately I'm not very familiar with the internals of the package -- simply a heavy user from the outside -- but if it's life or death, I can investigate whether I (or someone from my project's community) might be able to help with the burden here.
I see that @weierophinney has taken care of PHP 8 compatibility in release 2.12.0 (and I offer many thanks for that!). It seems there was some confusion, though, because if I'm reading the history correctly, it looks like he ended up having to recreate the work that was already done in #177 (which was closed without action based on discussion in #178). In any case, water under the bridge at this point, but just documenting here in case anyone is trying to follow this thread. :-)
If a little more participation on my part could help to keep this component alive in the future, please don't hesitate to reach out to me -- while my time is limited, I'm certainly willing to help if I can, and to spread the word that more maintainers are needed, if that would help.
@demiankatz Basically, the patch for PHP 8 support (#166) wouldn't pass unless I fixed the vsprintf()
issues; there were no open PRs at the time that resolved them, or I would have merged those first. :)