Drop official support for PHP 7.3 and below

[viktorix]

Officially drop support for PHP 7.3 and older. ClassicPress may continue to work with older PHP versions but we will not be performing tests for those older versions or releasing bug fixes. We may consider releasing a security update in the interest of public safety.

PHP supported versions:
https://www.php.net/supported-versions.php

[xxsimoxx]

We have to deprecate that in CP 1.6 if we want to follow SemVer best practices.

[mattyrob]

I was under the impression we only need to deprecate the public API, I'd don't think that really applies to moving forward with supported dependencies unless I'm missing something.
The release of a new Major version should be expected to have breaking changes - including for example, probably not working on PHP < 7.3

[viktorix]

I found an article discussing this, but it's a bit more specific to Composer:
https://medium.com/@sampart/semantic-versioning-when-you-change-the-required-programming-language-version-16a3a3555c95

[mattyrob]

I was looking here:

https://semver.org/

[viktorix]

I guess it really comes down to the interpretation of SemVer and is really up to us. In that article, it mentions Doctrine project which maintains several PHP libraries and how they dropped 7.3 support in a minor version.
https://www.doctrine-project.org/2017/07/25/php-7.1-requirement-and-composer.html#why-dropping-php-support-in-a-minor-version-is-not-a-bc-break

This is their reasoning and SemVer interpretation:

One question we frequently hear is, "isn't dropping support for a PHP version a BC break"? In a nutshell, no. A BC break happens when there is an incompatible change that your package manager can't handle. For example, changing a method signature in a minor version is a no-go, since the composer version constraints mentioned above assume any minor upgrade can safely be used.

However, when we drop support for an older version of PHP, composer will not consider the new version if the PHP version requirement is no longer fulfilled. Thus, you won't end up with a fatal error due to a wrong method signature, you just won't get the new version.

Either option is not wrong. So we must decide what we want to do.

[ClassyBot]

This issue has been mentioned on ClassicPress Forums. There might be relevant details there:

https://forums.classicpress.net/t/minimum-php-version-should-be-7-x/2887/4

[mattyrob]

I agree it's open to interpretation. One thing that swings it for me towards a major release bump is that ClassisPress isn't always installed by a package manager.

As per the outlined plan detailed some time ago by James, we certainly need a dashboard prompt to update PHP. My feeling is more inclined towards adding a message in v1 that PHP update is needed, especially now we officially support PHP 8.0.

Then in v2 we can drop support for PHP 7.x (specific minor version for debate and agreement) and lower.

[xxsimoxx]

I've read a lot on SemVer repo (there are endless issues about this) and agree that is subject to interpretations.
Said that, adding a notice in a v.1.x minor and then drop support in v.2 is my favorite way, and for sure this comply with SemVer.

[viktorix]

I think that's a good approach. @bahiirwa was working on the PHP version notice/API:

• Drop support for Older PHP Versions. ClassicPress-v1#25
• Add PHP upgrade notice ClassicPress-v1#266

And this is API:

• Add API endpoint for PHP version support checks ClassicPress-APIs#51

[viktorix]

One more issue related to PHP 5.6:

• Remove polyfills for php 5.6< ClassicPress-v1#133