-
Notifications
You must be signed in to change notification settings - Fork 187
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
Update to PHP7 #83
Update to PHP7 #83
Conversation
This is a major breaking change. I think this would require a new PSR? |
I'd say that a new PSR is not needed. This is a breaking change for a minor release. If this was merged and then released as 1.0.2 or 1.1 (the current next logical release numbers), current PHP 5.6 users would have a very bad time. To merge and release as a minor version is quite clearly a bad choice. This is not necessarily a breaking change for a major release. We could merge and release as 2.0. The 1.x releases would exist for legacy (PHP < 7) users. The 2.x and onwards releases would exist for PHP >= 7 users. Future changes would need to be applied to both the 1.x and 2.x releases. That's a little more work but given the relatively small size of this package I'd not consider the additional work to be overly burdensome. Is there any release policy that prevents this approach? |
...which reminds me that i already did this master...codemasher:type-hints-php7.1 |
@codemasher hello, by psr-12 reasons can you please add one space after the colon followed by the type declaration? Thanks. |
There you go: master...codemasher:type-hints-php7.1 I've also changed the |
Not needed. The whole serious developers use composer. Others may don't know about PSR. |
Have you considered files above ~2gb and integer overflow? Methods like |
This would only be a problem on 32bit flatforms. Its int in php, too: https://www.php.net/manual/en/streamwrapper.stream-seek.php |
In addition to a PHP 7 upgrade, i'd like to propose to allow chaining of
|
@McLotos What's holding the merge of this PR / releasing it back? |
@jasny Because this PR could be considered a change to the spec, and is certainly a major breaking change to the interface. There was discussion over if a new PSR is needed, or just a major version bump on the package. There are also implications for the virtual http-message package on packagist, which lots of people have dependence on |
@GrahamCampbell If the outcome of the discussion was that a new major version isn't an option, maybe close this (and other) PRs. At least, then it's clear they won't be merged. |
If other people uses wrong dependency version strings (e.g. This is only my opinion on this topic. |
Well, this was on a virtual package, which has no versions. |
I think, our discussion go to wrong way. What about this merge request and next public release? |
I don't agree. The PSR Amendments Bylaw doesn't allow changing the signature of interfaces, which blocks this PR: https://www.php-fig.org/bylaws/psr-amendments/. |
Well then I see 3 possible ways out of this dilemma:
I don't know if it is possible to do the first one. The second one causes a huge process I think and the last one is no option in my opinion. |
We've been discussing this kind of issues a lot lately, and we've condensed our proposed solution to updating PSR interfaces in a blog post. Please read it and provide your feedback! https://www.php-fig.org/blog/2019/10/upgrading-psr-interfaces/ |
Hi @GrahamCampbell ! 2 years yet have passed, so when we can get a typed version? =) |
An entire majpr PHP version has passed! Sorry, but at this point it seems more feasible to issue an RFC for PHP to allow adding method parameter type hints for poorly typed interface methods. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm now 👎 on the current form of this PR.
The bylaw for PSR evolution is now approved and in effect: https://www.php-fig.org/bylaws/psr-evolution/
It clearly states that we need a multi-step release, to avoid too many breaking changes. In particular, we need to add ONLY argument types first, and return types later with a major bump. We also need to require at least PHP ^7.2
.
It has already been rolled out for:
- PSR-13 Link: https://github.com/php-fig/link/releases/tag/2.0.0
- PSR-6 cache: https://github.com/php-fig/cache/releases/tag/3.0.0
- PSR-11 container: https://github.com/php-fig/container/releases/tag/2.0.0
With PSR-11 we got into some issues, but it's now resolved.
Ping @weierophinney who's the editor here.
But in other packages it already done |
V2.0 support >= 7.0 |
#94 and #95 do the appropriate steps that follow the PSR Evolution bylaw. As such, those will be what I use for the evolution vote, and I am closing this one. BTW, @oanhnn : please read the bylaw. Adding enums, readonly support, etc. is out of scope as that would be substantive changes to the spec, and would require a replacement PSR. |
current PSRs so outdated that it lost all reasons |
I think we should update to PHP 7 (like
psr/http-factory
package):