search

ClassicPress / wp-cms-experimental

ClassicPress v2.0 can be found here: https://github.com/ClassicPress/ClassicPress-v2
https://github.com/ClassicPress/ClassicPress-v2
2 stars 0 forks source link

Drop official support for PHP 7.3 and below #10

Open viktorix opened 1 year ago

viktorix commented 1 year ago

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 commented 1 year ago

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

mattyrob commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

I was looking here:

https://semver.org/

viktorix commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

And this is API:

viktorix commented 1 year ago

One more issue related to PHP 5.6: