jsonrainbow
Raise to PHP 7.2 minimum and add support for PHP 8.0 and 8.1
- PHP support since version 7.2;
- Support for php 8.0;
- Support for php 8.1.
what do u think about this? isn't it time to abandon the old versions of php? why do we need php 5? for whom?
@fenric This library is a dependency of composer, which is why the requirement for older PHP versions still persists. The minimum supported PHP version cannot be newer than the minimum supported version which composer supports, otherwise we'll break things.
@Seldaek What are your requirements for composer these days? Is 5.x still something you guys try to support?
@erayd why can't we support 5.x and 6.x versions of this package in parallel?
why can't we support 5.x and 6.x versions of this package in parallel?
@fenric Manpower. This project is extremely short of developer resource.
v6 and v5 already are supported in parallel to some extent (via the master & v5.x.x branches, with changes being backported from master to v5.x.x), but anything that diverges them adds maintenance overhead. As such, unless there is a very strong reason to drop support for older versions in master, it's best that we keep it.
IMO it's fine to drop <7.2, Composer as of 2.3.0 requires php >=7.2.5. We still maintain Composer 2.2 with PHP 5.3.3 support, but I'm happy to backport any critical fixes myself to the 5.x.x branch when needed.
I'd say 5.x.x can be more or less abandoned and the little resources we have here focused on getting 6.0 finished and released.
Shall we drop <7.2 or shall we try to support these? I'm done with #693, it's a questions whenever this makes sense.
As I said above, IMO drop <7.2 - it's not worth the maintenance trouble in the long run to keep supporting php5 and co. @erayd is definitely more of a decisionmaker here tho. Just my 2c.
I'm happy to follow your lead on this @Seldaek. Composer is basically the reason we support stuff that old anyway, so if you are comfortable with dropping those older versions now (and dealing with the headache of any critical fixes in the 5.x.x branch), then I reckon let's go for it.
Closing this PR as #746 is replacing this one. @fenric thanks for all the effort though. Many of the changes in this PR are valid and have found their way into the replacement PR.