EOL only when necessary

[JakeQZ]

Cyber-attacks tend occur after software providers diliberately drop support for older versions.

This happened in the UK with the WannaCry ransom attack on the NHS infrastructure, The attack was only possible because Microsoft dropped support for Windows 2000/XP, such that they would not even release fixes for known security vulnerabilities. Microsoft wanted to charge the NHS for an upgrade. There was no reason to upgrade; the systems in place were perfectly adequate to handle the admin of appointments, daignoses, etc. So the system was not patched and the whole of the UK health service infrastructure suffered two days of failed IT systems, and patients dying unneccessarily.

If we do not need to raise the minimum bar on PHP version, we should not. To improve robustness, we have used the type-safety features introduced in PHP 7.0 and 7.1. I don't see any reason to increase the minimum bar beyond that.

Just because PHP declares a version as EOL, doesn't mean we should drop it. Let users decide. I actually think PHP's approach is wrong. WordPress does much better by patching versions back to 10 years ago when a security vulnerability is found,

[oliverklee]

I agree.

In general, I'd raise the PHP minimum version for Emogrifier when we cannot easily run the unit tests on both the lowest as well as the highest PHP version, or when a dependency poses the same problem.

Should we document this approach in our README?

[JakeQZ]

Should we document this approach in our README?

I have always wondered why the 'Steps to release a new version' is in the README. It seems to belong elsewhere, e.g. CONTRIBUTING.md, where such statements about philosophical approach could also be included.

I agree.

In general, I'd raise the PHP minimum version for Emogrifier when we cannot easily run the unit tests on both the lowest as well as the highest PHP version, or when a dependency poses the same problem.

IIRC the dependency issues have been with PHPUnit itself and breaking changes between major releases therein, but hopefully it's settled down now.

For users, Composer should sort out dependencies.

Through the CI Github Action matrix we are testing against all PHP point releases from min to max.

Can we revert #1111? (I haven't tested.)

We can still retain the notes that certain older PHP versions are deprecated, but without actually forcibly forbidding them. E.g. HTML3 was deprecated while I was living in a different programming universe, but is still supported by all major browsers.