My opinion (from a not member) is PSR numbers for standars, semver for packages. This is not only about type hints, that could be solved using some of the techniques described. It’s about defining a standard way to upgrade a package adding breaking changes replacing other standard.
Let’s say, for example, that PSR-7 is replaced by PSR-33. The new version adds types to the interfaces, but also adds attribute methods to response (withAttribute, getAttribute). This change affects also to other related standards using PSR-7 like PSR-15 middlewares and PSR-17 factories. So, they should be upgraded to PSR-34 and PSR-35, in order to handle this new version of http messages. Having a project mixing all these old and new PSR is a bad idea. A middleware accepting PSR-7 and PSR-33? and creating a response using PSR-15 or PSR-34? I think mixing old deprecated versions and new versions should be avoided, and the way to do this is using semver. 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. > El 12 abr 2017, a las 14:05, Jordi Boggiano <j.boggi...@seld.be> escribió: > > Then maybe we have to ask ourselves.. Is it worth all the trouble just to add > a few type hints? > > Maybe it's best to delay any such changes until PHP 7.2 is out, and then new > PSR versions could be released like psr/log 1.1.0 could be released that > requires PHP 7.2, and adds type hints. > > As it seems 7.2 allows interface widening any library requiring PHP 7.2+ > could start requiring psr/log ^1.1 and implement the interfaces with the type > hints, while other libraries requiring ^1.0.0 would remain compatible with > 1.1.0. That way if you require any library that require 1.1 then you have to > upgrade but you need to run at least PHP 7.2. > > Best, > Jordi > > > On 2017-04-12 13:57 PM, Michael Mayer wrote: >> On Wednesday, April 12, 2017 at 1:18:48 PM UTC+2, Jordi Boggiano wrote: >> >> Same here. Especially as the way I see it, PSR v2's will really mostly >> be a thing as the library ecosystem transitions to PHP7, because of the >> added scalar hints. >> >> >> The benefit of migration because of scalar type declarations is >> extremely minor, especially in an established TDD process. >> >> >> Sure it will take some time for everything to migrate over, and it >> might >> lead to small periods of incompatibilities/dependency resolution >> conflicts along the way. >> >> >> fool/echolog <https://packagist.org/packages/fool/echolog >> <https://packagist.org/packages/fool/echolog>>, for example, >> still requires psr/log:1.0.0 (not ~1.0 or similar!), which makes it >> unusable at the moment. >> There is a PR >> <https://bitbucket.org/fool/echolog/pull-requests/2/expanded-psr-log-compatibility/diff >> >> <https://bitbucket.org/fool/echolog/pull-requests/2/expanded-psr-log-compatibility/diff>>, >> which is older than a half year. Well, that can be considered as a bug, >> but it is still not fixed. >> >> But, what amount of time are we talking about? If we consider PSR-7, >> then we have more than thousand packages (solely at packagist!) which >> dependent on it. >> Doing a BC by adding scalar type declarations (and doing a major version >> bump) will bring us years of dependency hell. >> >> PSR interfaces are not ordinary packages. Those interfaces were created >> to accomplish compatibility between projects, therefore a BC is a no go. >> >> Once we are through though we will be in a much >> more desirable outcome than if we have \V2 namespaces or whatever other >> similar hack. >> >> >> Indeed, V2 is really bad. >> >> -- >> 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 php-fig+unsubscr...@googlegroups.com >> <mailto:php-fig+unsubscr...@googlegroups.com> >> <mailto:php-fig+unsubscr...@googlegroups.com >> <mailto:php-fig+unsubscr...@googlegroups.com>>. >> To post to this group, send email to php-fig@googlegroups.com >> <mailto:php-fig@googlegroups.com> >> <mailto:php-fig@googlegroups.com <mailto:php-fig@googlegroups.com>>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/663d53aa-25f5-4d1c-b07d-5ded1d8912ce%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/663d53aa-25f5-4d1c-b07d-5ded1d8912ce%40googlegroups.com> >> <https://groups.google.com/d/msgid/php-fig/663d53aa-25f5-4d1c-b07d-5ded1d8912ce%40googlegroups.com?utm_medium=email&utm_source=footer >> >> <https://groups.google.com/d/msgid/php-fig/663d53aa-25f5-4d1c-b07d-5ded1d8912ce%40googlegroups.com?utm_medium=email&utm_source=footer>>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > Jordi Boggiano > @seldaek - http://seld.be <http://seld.be/> > > -- > 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 php-fig+unsubscr...@googlegroups.com > <mailto:php-fig+unsubscr...@googlegroups.com>. > To post to this group, send email to php-fig@googlegroups.com > <mailto:php-fig@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/083df612-8305-9205-0ef5-a85ab07e51f7%40seld.be > > <https://groups.google.com/d/msgid/php-fig/083df612-8305-9205-0ef5-a85ab07e51f7%40seld.be>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CDBFCE21-BA59-4372-9E8C-C48FCD255F2A%40gmail.com. For more options, visit https://groups.google.com/d/optout.