v6.1

[bshaffer]

Todo for v6.1

• Update minimum PHP version to 8.0
• Add union types
• Add return types
• Add typing for all class variables
• Use private constants
• Update all arrays to use [] array syntax

[peldax]

Hello,
is it worth it to still support PHP 5.4 at the end of 2021?
Why waste such rare opportunity to raise minimum to at least 7.2 and improve the codebase with strict types?

(Its an honest question, not meant to attack the decision in any way.)

[bshaffer]

It's a very good question! The reason I decided to not drop support in this version and keep it largely backwards compatible is that I wanted to encourage everyone to upgrade, as the 6.0 version represents a security improvement.

I can drop support for <7.2 and add typing in v6.1, and as long as the composer requirements are up to date, no major version is required.

That was my plan anyway. What do you think?

[peldax]

That sounds great, thanks for the answer. 👍🏻

[bshaffer]

Done in #386

[pabloelcolombiano]

@bshaffer is requiring PHP ^8.0 really important? You are making a big gap from ^5.3 to ^8.0.
If for any reason some critical security fix happens to be required, upgrading the plugin would require upgrading the PHP version of one's app.
I would consider ^7.1 a safe and typed enough PHP version to start with.
This is of course my opinion only. Let me know if this is worth opening an issue, or if this has been discussed by the community else where.

[bshaffer]

@pabloelcolombiano thank you for your feedback!

My reasoning is

1. Security fixes can still be added and tagged for previous versions of PHP, we would only need to create a branch from v6.0 to make them.
2. Union and mixed types are really important.

As you mentioned, having an intermediate step for 7.1 or 7.2 is also a possibility. As we have not tagged a version yet, this could still happen.

[pabloelcolombiano]

Thanks for your reply. I get your point. With cakephp/authentication requiring PHP ^7.2 (cakephp/cakephp ^4.0 => PHP ^7.2), if you lowered your requirements to 7.2, we could bump the package to ^6.0. If not, then there is no way to force the users using PHP 7.2, 7..3 and 7.4 to be at the latest state of security.

Using static analysis (e.g. PHPStan?) could counter back the inconvenience of not having union and mixed types.

PHP ^8.0 could be an option for v7.0.

This is open to discussion, of course.

PS: I open an issue and propose a PR to have PHPStan, or whatever other static analyzer, installed.

[bshaffer]

we could bump the package to ^6.0.

6.0 is already available and compatible with PHP 5.3

[pabloelcolombiano]

Yes, but v6.1 not. So we cannot bump to ^6.0, but only to <6.1. If v6.5 fixes a major issue, all apps with PHP 7.x cannot benefit from it (unless we branch v6.0.x, but this is going to make the maintenance horrible).

Generally speaking, this statistic shows that around 70% of the users of the package are on PHP 7.2, 7.3 or 7.4. This shows the proportion of users left behind by PHP >=8.0.