On Tue, May 9, 2017 at 10:44 AM, Jordi Boggiano <[email protected]> wrote:
> On 2017-05-08 17:32 PM, Larry Garfield wrote: > >> On 05/08/2017 05:42 AM, Jordi Boggiano wrote: >> >>> On 2017-05-08 03:01 AM, Larry Garfield wrote: >>> >>>> The simple answer is "well submit a PR to micahaelc/tortoise to update >>>> his version requirement, since we know it works." However, that >>>> introduces a new language version dependency on Tortoise which should be >>>> treated as a major version bump. It also means that Tortoise is now >>>> incompatible with philsturgeon/turtle, which is also using the 1.0 >>>> logger. Hence Phil needs to update his Turtle at the same time. (That >>>> sentence is begging to be OHed...) >>>> >>>> In short, it means that all 2494 PSR-3 using packages on packagist.org >>>> (as of this writing) need to all release a new major version *at the >>>> same time*. That's totally not going to happen. Or, someone needs to >>>> develop a bridge library called LogPlug that abstracts away the >>>> differences, which... rather defeats the whole purpose of having a PSR >>>> interface. >>>> >>> >>> Note that the packages could be updated to "psr/log": "^1.0 || ^2.0" >>> if 2.0 is compatible with implementations supporting 1.0. Then it's up >>> to the users to pick psr/log 1.0 or 2.0 based on the PHP version they >>> have, or preference or whatever. Both can coexist if the changes are >>> minor enough (adding scalar type hints for things that were already >>> enforced counts as minor IMO). Doing a change like that doesn't >>> require a major version bump. >>> >>> And no, not everything has to change overnight. It's much like when >>> Composer got started, nothing used it at first. If you wanted to use >>> it with a lib you had to send a PR with a composer.json to that lib.. >>> Things moved pretty fast that way, but not overnight, there's no need to. >>> >>> Best, >>> Jordi >>> >> >> The difference with Composer's initial adoption is that the presence of >> a composer.json file does not break the library for non-Composer-using >> projects. A dependency on a new version of a PSR definition package may >> break it for anyone who hasn't updated. >> > > Only for new versions of the package.. You can still use old versions just > fine though. People migrate at their own pace. > > And that is key in this to be honest. People will upgrade at their own and their projects' convenience. Having PSR-20 using the same FQCN as PSR-3 is the cleanest and more future proof option IMHO. Having 5 namespaces for the 'same' standard would create a mess and confusion. New major or minor versions is something we as developers are used to, namespacing each version not so much. Who knows what PHP 8 will bring, we might come up with PSR-80 that uses new and shiny features from it. I might end up writing wyrihaximus/cat that uses those features, which in turn will be incompatible with philsturgeon/turtle and micahaelc/tortoise unless they update. But in my humble opinion that is alright, and the way how software evolves over time. Projects are going to make choices based on what is compatible and what now and go with what is possible or create pull requests. -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAPY1sU9iDfKRoW%3Dmo_%2B5cLiDzmCRbMnzHv3SuEgWCwNOccFRXQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
