Enhancement: Add PHP version support policy

[localheinz]

What is the reason for this PR?

• [x] add a PHP version support policy

Related to #747.

💁‍♂️ Also see https://localheinz.com/articles/2023/09/12/adopting-a-reasonable-php-version-support-policy/.

Author's checklist

• [x] Follow the Contribution Guide

Summary of changes

Review checklist

• [x] All checks have passed
• [x] Changes are added to the CHANGELOG.md
• [x] Changes are approved by maintainer

[krsriq]

I think that FakerPHP should not be over-eager in dropping supported PHP versions; I understand the argument that not every FakerPHP user has the resources to keep their projects constantly up to date (even though that kind of makes me question their judgement of the technical debt incurred by using FakerPHP - or any technology for that matter). Limiting the supported PHP version of current FakerPHP releases to one year after EOL is imo a compromise that somewhat balances the work needed for users of FakerPHP to keep their projects up to date with PHP versions (or research how to use an older version of FakerPHP, or mabye even fork the project) with FakerPHP's maintainers' (and contributors') work needed to support older PHP versions.

Frankly I don't think that we should take extra-care of the set of users who 1. know how to install FakerPHP in a project and deploy said project in the first place and 2. are not aware of how to use (or research how to use) an older version of FakerPHP.

I also think that having a clear policy on what users can expect regarding this is important - I'd rather spend my time contributing to the future of FakerPHP than to contributing to recurring discussions about which PHP versions should be supported..

[deleugpn]

As I stated on the previous thread, Faker is not a common PHP library, it's a crucial component in automation tests across the PHP ecosystem. Faker is also useful for other PHP libraries to write tests for themselves and these libraries may have good reason to support a wider range of PHP versions. As a thought experiment, imagine if Composer had a dependency on Faker and then Faker makes the lives of Composer core developers harder by cutting PHP versions too soon.

To me it's a lot better to spend a few hours every year debating this subject back-and-forth than to take on a yearly decision to negatively impact projects that could otherwise make adoption of newer PHP version smoother.

@GrahamCampbell I understand and appreciate that we can all change our minds, but see > https://github.com/FakerPHP/Faker/pull/3#issuecomment-718147651:

I can't speak for Graham, but it looks to me like context might have been ignored here. Talking about dropping PHP 5 series in 2020 is not the same as talking about dropping PHP 7 series in 2023. PHP 5.6 was out of support for 2 years in 2020, not just 1.

@deleugpn What would be a justifiable reason?

What is the 8.0 feature that will improve Faker that cannot be used while 7.4 is still supported? What is the maintenance burden that comes with keeping a composer.json configuration that allows PHP 7.4?

Ultimately I see Faker as a feature-complete library that needs no change except adjustments to support newer PHP versions when they're released and if a new PHP version breaks Faker and it's hard for Faker to support both the oldest PHP version and the newest simultaneously, that's a great moment to drop the oldest one. But if there's no challenge in supporting a new PHP version, why make it harder for the PHP ecosystem to run their automation tests while upgrading their project? Most libraries can probably help PHP by dropping support and "pushing" the ecosystem forward, but a testing library doing it will accomplish the exact opposite, specially one that we have very little reason to use in production and it's mostly a require-dev dependency that helps users to know that they are safe to upgrade their dependencies.

[pimjansen]

I actually think this discussion goes way too far here. There is no added benefit in dropping a single php version if the lib does not require it.

For me personally php 8.x does that by making stuff strict and clean which we did for the core libs and 2.0 stuff we build.

But for here as well there is not a single benefit in dropping 8.0 because it goes out of support in 2023.

[TimWolla]

As per the issues #760 and #761 that I just filed, the real value-add comes with PHP 8.2 which introduced the new object-oriented random API (which will be further extended with PHP 8.3). Depending on the progress on Faker 2.0 it might make sense to raise the minimum version to PHP 8.2 or 8.3 for Faker 2.0 to leverage this new OO API which would allow to fix the reliance on global state as used by the horrible mt_rand() function [1]. Given that Faker 2.0 is a new major it doesn't appear to be inappropriate to use the opportunity to also migrate the internals to something that is actually properly seedable for use in testing.

[1] I plan to re-propose deprecating mt_rand() with PHP 8.4.

[localheinz]

@TimWolla

Also see #769 as an attempt to move the generation of (random) integers into a central place - this could accommodate for better algorithms than the ones that are available to us with the currently supported PHP versions

• 7.4
• 8.0
• 8.1
• 8.2

[bram-pkg]

Can we merge this, I think we've reached a majority of people agreeing, right?

[localheinz]

@bram-pkg

I think all we need here are a few approvals to move forward!