Hi Alessandro,

After I gave it more though, I agree that this idea will most probably work.
Thank you, Larry. The condensed proposal looks simple to read and
understand.

The main advantage of this proposal that I didn't understood before is that
new versions of libraries with parameter and return type declared can be
installed and coexist with a library that didn't upgrade anything but did
just the small change to allow also v2.

Alex


On Fri, Oct 4, 2019 at 4:57 PM Alessandro Lai <alessandro.la...@gmail.com>
wrote:

> Adrien the issue lies in the fact that in that way you would be forced to
> update ALL the dependencies that rely on that interface. In the case of
> very common PSRs, like psr/log, that would mean being blocked a lot, and
> having to be forced to do a big-bang update with a single deploy, and no
> way to split that up in any way. That's bad.
>
> In the meantime, with Larry's help, we condensed the proposal in a blog
> post that we just published, followed by a poll to get some feedback;
> please read and give us your opinion:
> https://www.php-fig.org/blog/2019/10/upgrading-psr-interfaces/
>
> Il giorno giovedì 19 settembre 2019 21:23:58 UTC+2, Adrien Crivelli ha
> scritto:
>>
>>
>> On Thursday, 19 September 2019 00:27:09 UTC-7, Alexandru Pătrănescu wrote:
>>>
>>> we would want to allow upgrading major version of slim without upgrading
>>> to a major version of guzzle.
>>>
>>
>> You assume that this is a requirement, to be able to upgrade major
>> version independently. I am saying that this is not a requirement, and it
>> should not be.
>>
>> The exact same problem of being forced to wait for both libs to be
>> upgraded before you can upgrade your own project already exists today in
>> composer ecosystem. And it is already solved simply by having a little bit
>> of patience and/or contributing to libs to upgrade them. I really don't see
>> why PSR should have a special status and be managed differently than the
>> entire composer ecosystem.
>>
> --
> 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/675f1982-3f17-4a73-96f2-4bfb84df679f%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/675f1982-3f17-4a73-96f2-4bfb84df679f%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/CAAwdEzD3hao23ZHY14XFWdE8K%2B1g9i74YihehQXLrBXCJpWPWg%40mail.gmail.com.
              • ... Alessandro Lai
              • ... Alexandru Pătrănescu
              • ... 'Edward Almasy' via PHP Framework Interoperability Group
              • ... Adrien Crivelli
              • ... Alexandru Pătrănescu
              • ... 'Alexander Makarow' via PHP Framework Interoperability Group
              • ... Alexandru Pătrănescu
              • ... Alessandro Lai
              • ... Adrien Crivelli
              • ... Alessandro Lai
              • ... Alexandru Pătrănescu
  • Re: [BYLAW] P... G. P. B.

Reply via email to