Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support PHP 5 #2

Closed
XedinUnknown opened this issue Apr 13, 2018 · 10 comments

Comments

@XedinUnknown
Copy link

commented Apr 13, 2018

Hi!

Similarly to php-fig/http-server-handler#3, the only thing that makes this package require PHP 7 is the return typehint of MiddlewareInterface#process().

Could this be removed in favour of PHPDoc, so as to make PHP 5 implementations possible?

@shadowhand

This comment has been minimized.

@devtronic

This comment has been minimized.

Copy link

commented Sep 10, 2019

Any news on this? A possible way could be:

  • Create a v1.0.0 Branch/Release which supports PHP5+
  • Create a v2.0.0 Branch/Release which supports PHP7+
@Jean85

This comment has been minimized.

Copy link
Member

commented Sep 10, 2019

Backporting to PHP5 at this time, which is EOL by nearly a year by now is not something to pursue, IMHO.

@devtronic

This comment has been minimized.

Copy link

commented Sep 10, 2019

It's a 5 minute job...

  • Clone
  • Remove the type hint, add a phpdoc comment, update composer.json that only php ^5.6 is supported
  • commit push
  • revert the changes, commit push
  • create a new release only for PHP 5.6 @ the second last commit

The users which use the current version don't see any changes because the version constraint is currently PHP7+ and the fix will only for PHP >=5.6<6

If you confirm that you create a release I can work on the changes.

@shadowhand

This comment has been minimized.

Copy link
Collaborator

commented Sep 10, 2019

PHP 5.x is a EOL and therefore security risk. I will not help facilitate developers willfully exposing themselves to reduced security.

@shadowhand shadowhand closed this Sep 10, 2019

@Jean85

This comment has been minimized.

Copy link
Member

commented Sep 10, 2019

@devtronic you're suggesting a simplistic solution that wouldn't work. Your package wouldn't be usable since it would be a simple interface. Changing it wouldn't change the ecosystem of packages that implements that interface, and since they give PHP 7 for granted, they will not alter their entire codebase for you.

At that point, it's best if you fork what you need, without making all the others go through the trouble of creating possible Composer & versions corner cases; with, on top of that, security and portability concerns.

@XedinUnknown

This comment has been minimized.

Copy link
Author

commented Sep 11, 2019

Please understand this. There are ecosystems (such as WordPress) with hundreds of thousands of hosts running PHP 5. This means that they are running on platforms with security vulnerability per se, not due to using this package. The only difference is that they won't be able to use the interoperability layer provided here. The consequences of not having a PHP 5 version available are only negative. If a user needs to run PHP 5 code, simply not giving them PHP 5 interfaces will not solve any problems. Instead, it will create problems with interoperability.

@XedinUnknown

This comment has been minimized.

Copy link
Author

commented Sep 11, 2019

It is already a miracle that PHP 5 developers (e.g. WP) express interest in using interop standards like the PSRs. Not having PHP 5 versions available will simply discourage further interest and usage of interop interfaces.

By the way, not trying to say here that every interop package should have a PHP 5 version available. Just saying that in this case, it really is a 5 minute job. But doing so will allow flexibility for possibly hundreds of projects.

Please re-consider.

@shadowhand

This comment has been minimized.

Copy link
Collaborator

commented Sep 11, 2019

Just saying that in this case, it really is a 5 minute job. But doing so will allow flexibility for possibly hundreds of projects.

It is not. As @Jean85 pointed out, having a PHP 5.x version of this interface wouldn't work because every package that depends on it would also need to have 2 versions available. PHP 5.x was EOL before this PSR was approved. There are very good reasons for PSRs to not support EOL releases.

@php-fig php-fig locked as resolved and limited conversation to collaborators Sep 11, 2019

@Jean85

This comment has been minimized.

Copy link
Member

commented Sep 13, 2019

@XedinUnknown I would also add that even WordPress is pushing toward upgrading, since their latest release requires PHP 7, and right now they're suggesting 7.3: https://wordpress.org/about/requirements/

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
4 participants
You can’t perform that action at this time.