3 ms·

In the unfashionable PHP world the Packagist libraries tend to be very strict about following semver.

jarofgreen 9y ago
Do you have specific examples? Given that any idiot can publish a packagist library (Hello!) that's kind of like saying "The code on GitHub does". I'll start by saying Symfony seems pretty good.
- w0rd-driven 9y ago
  I have a specific example of one that bit me recently using Laravel, which has these doctrine dependencies upstream. On my mac I'm running php7.1 because it made sense as most of the code I write is served there now finally but there are some major projects stuck on 5.6 servers. As such I was recently bitten by this: http://doctrine-project.org/2017/07/25/php-7.1-requirement-and-composer.html http://doctrine-project.org/2017/07/25/php-7.1-requirement-a.... There about 7 packages listed there. Each github repo has at least one closed issue about this change, likely spurring the article. Knowing the fix of 'pinning' my platform to 5.6 is such an easy fix but what I had to Google to get there absolutely was not. I feel in this instance that the concept of a platform dependency like PHP is or say the underlying Node.js engine is wildly different than an upstream library. The solace I get with node is often the jump from say 4 to 8 breaks a ton of shit. The jump from PHP 5.x to 7.x breaks exactly none of my code. I believe if it had I wouldn't have jumped to it so eagerly, even though PHPStorm does a wonderful job at keeping me from using 7.x things when I specify a project is 5.6. I ultimately recognize now that I am the one that put myself in this situation but I feel like library maintainers could do a better job to prevent me from shooting myself in the foot. I know now to pin to very specific major.minor numbers at the very least and proposed that Laravel add the platform config flag to save other similar developers from making the mistake. The problem wasn't that just Laravel pinned to 1.* but that doctrine's own common package did it as well. If the platform config option didn't work another choice was to pin the specific version of upstream packages in Laravel's composer.json. That version of the fix feels like I'm ignoring most of the benefits composer was supposed to give me in the first place. I know the node ecosystem can suffer a similar fate just as easily but it feels really dirty to be in that situation. I start to wonder if I shouldn't be using those packages at all.

Do you have specific examples? Given that any idiot can publish a packagist library (Hello!) that's kind of like saying "The code on GitHub does". I'll start by saying Symfony seems pretty good.

w0rd-driven 9y ago
I have a specific example of one that bit me recently using Laravel, which has these doctrine dependencies upstream. On my mac I'm running php7.1 because it made sense as most of the code I write is served there now finally but there are some major projects stuck on 5.6 servers. As such I was recently bitten by this: http://doctrine-project.org/2017/07/25/php-7.1-requirement-and-composer.html http://doctrine-project.org/2017/07/25/php-7.1-requirement-a.... There about 7 packages listed there. Each github repo has at least one closed issue about this change, likely spurring the article. Knowing the fix of 'pinning' my platform to 5.6 is such an easy fix but what I had to Google to get there absolutely was not. I feel in this instance that the concept of a platform dependency like PHP is or say the underlying Node.js engine is wildly different than an upstream library. The solace I get with node is often the jump from say 4 to 8 breaks a ton of shit. The jump from PHP 5.x to 7.x breaks exactly none of my code. I believe if it had I wouldn't have jumped to it so eagerly, even though PHPStorm does a wonderful job at keeping me from using 7.x things when I specify a project is 5.6. I ultimately recognize now that I am the one that put myself in this situation but I feel like library maintainers could do a better job to prevent me from shooting myself in the foot. I know now to pin to very specific major.minor numbers at the very least and proposed that Laravel add the platform config flag to save other similar developers from making the mistake. The problem wasn't that just Laravel pinned to 1.* but that doctrine's own common package did it as well. If the platform config option didn't work another choice was to pin the specific version of upstream packages in Laravel's composer.json. That version of the fix feels like I'm ignoring most of the benefits composer was supposed to give me in the first place. I know the node ecosystem can suffer a similar fate just as easily but it feels really dirty to be in that situation. I start to wonder if I shouldn't be using those packages at all.