REMINDER: Discussion period ends this coming Monday, March 13, after which I'll open the vote with the CC.
We've had a few rounds of discussion and a few comments, mostly around the choice of PHP version constraints. I'm going both simultaneously less restrictive (allowing PHP 7 versions, as there are LTS versions of PHP in the ecosystem — some advocated for jumping directly to 8) and more restrictive (not doing a >= 8 constraint, but instead ^8.0, as compatibility with a new major is not guaranteed). Please review the PRs and let me know early if you see anything glaring that should be changed before voting. On Mon, Feb 27, 2023 at 1:54 PM Matthew Weier O'Phinney < [email protected]> wrote: > Hi, all! > > This proposal has been a long time coming: formal addition of parameter > and return type declarations for PSR-7. > > I'd like to thank GitHub user @stilch for creating the patches and being > patient enough to wait almost two years for me to get around to testing, > reviewing, and creating the proposal. > > In sum, this a proposal following our PSR Evolution bylaws ( > https://www.php-fig.org/bylaws/psr-evolution/) to update PSR-7 to: > > - Create a version 1.1 of the interfaces that adds parameter type > declarations (see https://github.com/php-fig/http-message/pull/94) > - Create a version 2.0 of the interfaces that adds return type > declarations (see https://github.com/php-fig/http-message/pull/95) > > The PSR-7 spec changes can be found here: > https://github.com/php-fig/fig-standards/pull/1296 > > I have tested the changes against the PSR-7 integration test suite, > Diactoros, and a variety of real-world applications. For consumers, > generally no changes are necessary; applications I had "just worked". For > implementers, the primary change is that a fair amount of code used to > validate parameter input can be removed, though in order to comply with the > spec, they must also ensure that they add return type hints at the minimum > for a new MAJOR version (this is documented as part of the Evolution > by-laws anyways). Assuming passage of the specification, Diactoros, at the > very least, can be updated within a day as I've already got patches > prepared for new minor and major versions, and the changes result in a net > removal of code, and fewer errors flagged by Psalm. I consider this a net > win! > > The other ecosystem concern will be PSR-15, PSR-17, and PSR-18. Each of > these consumes PSR-7, so at the minimum, they will need to release new > minor versions that allow usage of either ^1.0 or ^2.0 of the > psr/http-message package. I've already notified Woody Gilk so he can track > the updates. > > At this point, I'm opening a 2 week comment period before calling a vote. > > -- > Matthew Weier O'Phinney > [email protected] > https://mwop.net/ > he/him > -- Matthew Weier O'Phinney [email protected] https://mwop.net/ he/him -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myXf0MyBjvgGRzrzPdhLtEo9HnJLYXUve1dhEA2EiCH%3DRA%40mail.gmail.com.
