EHLO, >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. Even though PSR-0 is deprecated you can still use it in composer today.
For example we do a follow up on PSR-3 adding (return) type hints. We would deprecated PSR-3 in favour of the new PSR, tag v2.0.0 on the psr/log package and watch as all package maintainers slowly upgrade their packages to the new PSR. At some point all packages you use in your projects will have upgraded and you can upgrade to PSR-3NEXT. (Dependabot is a great tool to automate that.) This is the way is goes with any package, whether it's a small library or a mayor framework. I don't see why our PSR's should be any different from the already unwritten conventions and ways of working in the community. Yes that means it might take a while before you can upgrade, and yes that means effort from package maintainers to update and release a new version. But we as a community can help with that. With all respect to you and your idea Stefano but it feels like a bureaucrats way of solving a developer problem. This problem IMHO needs a very simple solution, not a one that will complicate the ecosystem over time. And I'm afraid that with using versioned namespaces and package names will lead to more fragmentation. The beauty of having these PSR's is that you can rely on everything in your application behaving the same way. And tbh I really don't want two different PSR-7's in my applications, I want one where I can rely on that everything in the applications follows that specific version of the spec. On Wed, Sep 18, 2019 at 5:52 PM Stefano Torresi <stef...@torresi.io> wrote: > Hey Ale, > > Can we push this forward somehow? >> > > My proposal didn't receive much feedback tbh, but nobody proposed > alternatives. > > > I have one doubt: using this namespace strategy, it seems to me that a >>> consumer of the spec can only require one revision at a time, is that >>> correct (and desired)? >>> >> > Nope, that's quite the opposite: having the revision in the namespace > *and* in the package name means multiple revisions can be imported in the > same codebase, which solves the main problem of being able to provide > migration paths to BC breaks. > This is actually the main point that should justify the clunkiness of the > proposal. > > I would invite all the people in the group to provide feedback, expecially > negative, so that we can asses if there is ground to start editing a new > bylaw and finally get things moving. > > Cheers! > Stefano > > -- > 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/CAFojS1ui6M7EZH5hnTh64enmRhX-HxPd7bw5-DELTxa_7R2xaQ%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAFojS1ui6M7EZH5hnTh64enmRhX-HxPd7bw5-DELTxa_7R2xaQ%40mail.gmail.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/CAPY1sU8XE16YgQihG%2BcU-v8T4B3LQjowc3LaMY%3Du0%3DEBt6C2Kw%40mail.gmail.com.
