search

php-http / client-common

Common HTTP Client implementations and tools for HTTPlug
http://httplug.io
MIT License
1.01k stars 53 forks source link

Drop Symfony 2 support #206

Closed martinssipenko closed 3 years ago

martinssipenko commented 3 years ago

Description Are there any plans to drop support for Symfony 2, which is no longer maintained?

Additional context

I'm currently facing some issues with PHP8 as this package allows symfony/options-resolver as low as 2.6 which uses deprecated ReflectionParameter::getClass() method. This was fixed in supported versions 3.4.43, 4.4.9, 5.1.0.

GrahamCampbell commented 3 years ago

I don't see how this is an issue. PHP 8 users can just not use that version?

martinssipenko commented 3 years ago

I do agree it's not really an issue. I do get deprecation warnings when using this lib on php8 with --prefer-lowest, so I somewhat feel that, while it is just a deprecation notice and the package is php8 compatible, it's could drop support for Symfony 2.

GrahamCampbell commented 3 years ago

Even if 2.x were dropped, you;d still have that issue, since the 3.x version you;d get would exibit the issue.

The real issue here is that Symfony refuses to use upper bounds on their php versions, which means that prefer-lowest on super new php versions picks up packages that should never have been marked as compatible.

NB Symfony have their reasons for this, but this is the main side affect of that choice.

martinssipenko commented 3 years ago

I think it was fixed in 3.4.43, wouldn't setting that as minimum (and dropping 2.x) fix this?

dbu commented 3 years ago

the lowest versions is about providing something that works together for legacy systems. i would not drop a lowest version because it uses a deprecated method of another component.

my assumption is that most people either install the latest versions, or they don't upgrade their core parts for reasons but are glad to be able to add something to php-http (or also during a refactoring to allow to later upgrade).

if lowest would end up triggering an error because one component ends up being a new version that removed a deprecated method, i could see bumping the version of our requirements, but warnings are not errors and nothing is wrong with a legacy application calling deprecated methods.