Since there seems to be a lot of confusion about what changes could be made code-wise and what not, I prepared a summary table for all the combinations of possible versions, using PSR-3 and Monolog v1-v2 as test subjects:
https://docs.google.com/spreadsheets/d/1QY7AUVQbWnVCbOZqJX11tbz2gKr-pU0CeZezcyJsEPA It's basically a double-entry table with all the combinations of with/without argument/return types, on both sides (interface & concrete implementation); I've linked 3v4l pages for all the entries, except the trivial ones on the diagonal where interface and implementation match perfectly. As you can see it's quite the minefield, and trying to add only the return type to the interface (column D) is a complete disaster, as it's broken in all cases except a perfect match; but I've highlighted in green what seems to me a good upgrade path, both on the PSR side, that for the implementation. The path is as follows: psr/log v1, as we know it: log($level, $message, array $context = []) psr/log v2, adds argument types: log(string $level, string $message, array $context = []); (REQUIRES PHP 7.2) psr/log v3, adds both types: log(string $level, string $message, array $context = []): void; (REQUIRES PHP 7.2) Monolog v1 (as released): compatible with both psr/log v1 & v2 Monolog v2 (as released, adds return type): compatible with all psr/log versions Monolog v3 (adds both return and arguments types): compatible with both psr/log v2 & v3 So, basically every version from Monolog is compatible with at least two adjacent versions of the interface. This seems to me a perfect upgrade path, that would require a new PSR only for the last step, because PSR-3 would be compatible with v1 and v2, and PSR-3-next would be declared compatible with v2 and v3. This would mean no need to change package and/or namespaces, the interface would remain the same, it would just evolve through SemVer with a "bridge" version between the two (nearly identical) PSRs. Obviously PSR-3 would require an amendment, but it would just to declare the compatibility with the bridge version, and announce the future deprecation in favor of the new one. If this seems reasonable to you, tomorrow I'll try to draft a PR to the bylaws to have an actual text to discuss over. Il giorno mercoledì 18 settembre 2019 21:07:39 UTC+2, Cees-Jan Kiewiet ha scritto: > > 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/a9ae0dd1-e07f-4cb5-a8d2-8e2928378d1e%40googlegroups.com.
