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.

[oliverklee]

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.

That's because we started with only the README for our documentation, and so far nobody has bothered to move more things out of the README into other documents.

As far as our approach to the PHP version support is concerned, I think that's helpful for users of out library and hence should stay in the README.

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

Yes, we probably can. PHP 7.2 is the minimum required PHP version for PHPUnit 8.x (the first PHPUnit major version that actually works up to PHP 8.2.) I have just created the #1207 for this.