I apologize if my answer didn't provide clearer cases where this solution that seems to be the simplest one is just not working:
- If I have a small project where I use slim framework and guzzle http client, both having implementation of PSR-7, I should be allowed to upgrade each one to another major version with no impact on the other. If the project is bigger, you might find more than two implementations, including PSR-17 factories that also implements PSR-7. - Another example would be the case of PSR-11, the container interoperability interface and actually all interop related PSR that by design are meant to allow projects with more than one implementation at runtime. There are problems that could require a more complex solution, but still the simplest that would work. I believe namespaced interfaces would be needed here. Alex On Thu, Sep 19, 2019 at 7:40 AM Adrien Crivelli <adrien.crive...@gmail.com> wrote: > > On Wednesday, 18 September 2019 17:17:29 UTC-7, Edward Almasy wrote: >> >> On Sep 18, 2019, at 2:07pm, Cees-Jan Kiewiet <cees...@gmail.com> wrote: >> >> From a consumers perspective the namespaced revisions sounds like hell to >> me to be honest. As a consumer I care about the highlevel >> Psr\Log\LoggerInterface interface, not whether it's rev1, 2, or 35. To me >> the packages for each PSR should be handled like any other PHP package and >> receive major new versions introduction updates/maintenance for that >> package. And as a consequence only one version of a PSR should be active, >> like PSR-12 supersedes PSR-2 or PSR-4 supersedes PSR-0. This means that >> consumers should always be moving forward, but at their own pace. >> >> >> I'd like to second this sentiment. Simplicity promotes clarity and >> adoption >> > > Me too, find that using the de-facto standard of managing dependencies and > their breaking version is the simplest and best way to approach this. > > If your lib inherit from a PSR interface, then you cannot support both PSR > major versions at once, but you can, and should, release a new major of > your lib with the support of latest PSR version. This is how it is done for > pretty much everything else since composer came to be. I don't see why it > could not be applied to PSR too. > > Please, Keep It Stupid Simple. > > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/0e8c8755-e554-429b-bf45-639d57d97574%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/0e8c8755-e554-429b-bf45-639d57d97574%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAwdEzDCm7Dj3ucj1CKE9OkgQdQ8p-Y-9sT_41dSUr0niBDJ%3DA%40mail.gmail.com.
