We should distinguish 3 cases: 1. non-BCs, like adding methods etc. 2. BCs for some PHP versions, like adding parameter type declarations 3. BCs for all PHP versions, like adding return type declarations
It would be advisable to focus on case 3. first – the other cases may depend on the outcome of it. On Thursday, April 13, 2017 at 12:35:12 PM UTC+2, Oscar Otero wrote: > If you want to use the new PSR-33 http messages, make sure that all of > your dependencies are upgraded to use these new version, otherwise, keep > using PSR-7. > This presupposes, that it is possible to upgrade all dependencies, which is often not the case. Sometimes it is not practicable because of the amount of packages, sometimes it is not possible because of licensing issues (closed source etc.). IMO, it should be possible to migrate softly to a new PSR – FIG stands for Framework *Interoperability* Group and it would be a shame, if the FIG cannot achieve interop of their very own Standards Recommendations. From Wikipedia: *Interoperability* is a characteristic of a product or system, whose > interfaces are completely understood, to work with other products or > systems, *present or future*, in either implementation or access, without > any restrictions. "present or future" is crucial – a BC in conjunction with a major version bump prevents interop of present and future implementations. -- 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 post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/97c517fa-051a-4e20-9ada-c941427b390b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
