add psr/log 3, phpstan, drop unsupported PHP #30
Conversation
composer.json
Outdated
| @@ -9,18 +9,19 @@ | |||
| } | |||
| ], | |||
| "require": { | |||
| "php": "^7.2 || ^8.0", | |||
| "php": "^8.3", | |||
There was a problem hiding this comment.
Hm, IMO it might be too aggressive for this bundle, no? Also, PHP 8.1 & 8.2 still support security fixes. Even Sf 7.3 requires 8.2
There was a problem hiding this comment.
well, maybe. But if this is going to be a completely new release, we could be this aggressive. But the important thing (to me) is to drop php 7.
There was a problem hiding this comment.
If it's a well-grounded change - I'm fine with it. I mean, why exactly should we use 8.3 and makes problems for people who are still on 8.2? Do we use any new syntax from 8.3 that requires as for this move? Of not - I would prefer to keep 8.2 users covered still. But also, what about LTS Symfony 6.4? I suppose we do want to support that version as well, and that version requires >=8.1. Unless we have strong arguments why it should be 8.3 - I think we can make PHP constraints not that strict IMO
There was a problem hiding this comment.
But ok, we can think about the exact PHP version constraint later before the release, probably it would be more obvious base on the actual changes
composer.json
Outdated
| }, | ||
| "require-dev": { | ||
| "phpunit/phpunit": "^8.4", | ||
| "nyholm/nsa": "^1.1", | ||
| "php-http/curl-client": "^1.0 || ^2.0", | ||
| "php-http/message": "^1.8", | ||
| "nyholm/psr7": "^1.2" | ||
| "nyholm/psr7": "^1.2", | ||
| "phpstan/phpstan": "^2.1" |
There was a problem hiding this comment.
Why do we add PHPStan as a direct dependency here?
There was a problem hiding this comment.
I love phpstan, especially for checking php 8.4 compatibility. But of course we don't need it, I could just keep it in my branch.
There was a problem hiding this comment.
IIRC you can install PHPStan globally locally and use it, right? I mean, it doesn't have to be a direct dependency? Correct me if I'm wrong but lately using SA tools as direct dependencies is not the best practice anymore?
|
I don't use this package lately, but I don't want to block you from pushing things forward here, so as I see we have a few options:
As I understand you're leaning toward going with the 2nd option? just to clarify things. I'm fine with both ways if it helps to push things forward better/easier |
|
I've pushed the changes you've suggested.
Yes, that's my preference, because we can break things while we're working! Like using symfony/contracts and dropping the guzzle dependencies (and making them optional). |
|
I created a I'm not sure we should support different branches e.g. 1.x & 2.x as Symfony do in their repos, so I hope a dedicated |
This could be a starting point for a 2.0-dev branch.