Dropping support for PHP versions < 7.3

[meyfa]

We are missing out on a lot of features due to our requirement of supporting PHP versions down to 5.3.3. Additionally, we are limited to PHPUnit 4.8, since PHPUnit 5 requires PHP >=5.6. Up to PHP 8.0, we were able to polyfill any incompatibilities between PHP and PHPUnit, but PHP 8.1 introduced even more changes that we may not be able to patch.

On the one hand, I'm very reluctant to drop PHP version support because this entire project started as an alternative to Imagick/Gmagick, which are often unavailable on cheap hosting providers, which coincidentally often have outdated PHP versions. On the other hand, I really really really hope that's not the case any more, and even if it is, we probably shouldn't let them limit us.

[Niellles]

IMO older versions (i.e. <=5.6 or even <=7.4) should be dropped for the latest and greatest; the test suite isn't running on PHP 8.1 and we have PHP 8.2 coming up next month. However, I may be a bit biased because I need this in a project that runs on 8.1. (I suspect it might run fine, just would very much like to have it officially supported.)

That being said I think it's nice to support older versions, if possible. Especially given:

(...) alternative to Imagick/Gmagick, which are often unavailable on cheap hosting providers, which coincidentally often have outdated PHP versions.

As far as I can see atm the main problem is the test suite not running on PHP >= 8.1. So far I haven't really seen any issues with the code itself. Although there may be a couple small ones (and having the latest PHP features would be nice too of course).

What I would do is split up into two branches: release-0.x and release-1.x (asap). release-1.x can then be set up to drop some older PHP versions. Probably everything under PHP 7.2 could be dropped as this would bring us up to PHPUnit 8.0. Although I haven't investigated yet whether PHPUnit 5 would also be ok (ran into some problems with meyfa/phpunit-assert-gd requiring phpunit ^4.8 which shouldn't take too long to fix locally for investigating purposes).

Anyway, once the dependencies have been upgraded in release-1.x we should be able to release a v1.0.0 with support for PHP 8.1 as well as 8.2. (Most likely everything above PHP 7.2, although this requires further investigation).

After that we can add some features in 0.12 (probably a limited scope as you mentioned) the features can be easily implemented in 1.x too as the versions haven't diverted much at this point (no differences except PHPUnit requirement).

After that there might be some extra features that would be nice to add in 0.x (v.0.13?) or we (i.e. you) might decide to drop support on 0-x (might make some features easier to implement as I noticed some issues that had comments about solutions being harder to create in older PHP versions).

After v0.13 (if this version ever sees the light of day) it's probably time to drop the older PHP versions. Do some re-factoring of the code, etc., in the new 1.x release.

[Niellles]

As for the v0.12.0 milestone I am not sure whether I can help too much with that. SVG isn't exactly my speciality, so there may be some challenges there -- although I could give it a shot. (Unfortunately my time is quiet limited too.)

I'd be happy to help out with getting a (1.0.0) version released that runs the tests on newer PHP versions though.

[mprins]

With php 7.x now completely unsupported it would be good to take advantage of that and drop any support for that or at least make sure things work on supported php versions.
Ppl on EOL php can always use previous releases, just like they are using insecure runtimes ...

[Niellles]

With php 7.x now completely unsupported it would be good to take advantage of that and drop any support for that or at least make sure things work on supported php versions.
Ppl on EOL php can always use previous releases, just like they are using insecure runtimes ...

Agreed. We should definitely be supporting the latest PHP versions, which currently we aren't (8.1 and 8.2 aren't officially supported atm).

I can draft a MR to upgrade to PHPUnit 9.0.. we can then support > PHP 7.3 on a 1.0.0 release. Which is still quiet lenient on people that can't/don't upgrade. Honestly, if you're cheap hosting provider still hasn't update to 7.3, you probably should be moving you're stuff anyway.

[meyfa]

I agree with both of you, and given that there weren't any voices against, I say we go ahead and raise the version requirement.
My plan looks as follows:

1. Release v0.12.0 from current main branch.
2. Perform the necessary changes to support PHP >= 7.3, and set the version requirement to that.
3. Release as v0.13.0.

The overwhelming majority of installations should already be running PHP >= 7.3, and PHP 7.3 lets us use the newest PHPUnit. We may move towards PHP >= 8.0 at a later point (v1.0.0?), if needed.

I wouldn't want to bother with maintaining two separate release lines in parallel, if we end up dropping one of them soon after anyway. Also, I'm rather reluctant to releasing a v1.0.0 at this point. There are some changes to the API surface I'd like to have happen before that.

[meyfa]

Step 1 done: v0.12.0 is released.

[meyfa]

Step 2 done as well:

• PHP 5 support dropped in chore!: Drop support for PHP versions older than 7.3 (closes #180) #182.
• CI tests enabled in chore: Run CI tests also on PHP 8.1 and 8.2 #185.

I'll probably create the v0.13.0 release tomorrow.

[meyfa]

https://github.com/meyfa/php-svg/releases/tag/v0.13.0