Enhancement: Add PHP version support policy #752
Conversation
| @@ -99,6 +99,10 @@ return static function (Config\RectorConfig $rectorConfig): void { | |||
|
|
|||
| Faker is released under the MIT License. See [`LICENSE`](LICENSE) for details. | |||
|
|
|||
| ## PHP Version Support Policy | |||
|
|
|||
| The maintainers of this package add support for a PHP version following its initial release and drop support for a PHP version one year after it has reached its end of security support. | |||
There was a problem hiding this comment.
This may or may not reflect the current implicit PHP version support policy.
There was a problem hiding this comment.
I'd rather make this 2 or 3 years.
There was a problem hiding this comment.
I honestly think one full year after security support ends, is already pretty long.
There was a problem hiding this comment.
This is only free security support from php.net. Many users receive extended support from third parties, both free and paid. Given faker is a library used for testing, it is convenient to support as wide a range of PHP versions as possible.
There was a problem hiding this comment.
I'd rather make this 2 or 3 years.
If we drop support for a PHP version one year after it has reached its end of security support, we would need to support
7.48.08.18.2
today (which we currently do).
If we drop support for a PHP version two years after it has reached its end of security support, we would need to support
7.37.48.08.18.2
today.
If we drop support for a PHP version three years after it has reached its end of security support, we would need to support
7.27.37.48.08.18.2
today.
Quick overview of the lifecycle of PHP versions
7.0- initial release on December 3, 2015
- active support ended on January 4, 2018
- security support ended on January 10, 2019
7.1- initial release on December 1, 2016
- active support ended on December 1, 2018
- security support ended on December 1, 2019
7.2- initial release on November 30, 2017
- active support ended on November 30, 2019
- security support ended on November 30, 2020
7.3- initial release on December 6, 2018
- active support ended on December 6, 2020
- security support ended on December 6, 2021
7.4- initial release on November 28, 2019
- active support ended on November 28, 2021
- security support ended on November 28, 2022
8.0- initial release on November 26, 2020
- active support ended on November 26, 2022
- security support ends on November 26, 2023
8.1- initial release on November 25, 2021
- active support ends on November 25, 2023
8.2- initial release on December 8, 2022
- active support ends on December 8, 2024
There was a problem hiding this comment.
and do the sensible thing on applicable branches
There was a problem hiding this comment.
The policy could also be:
- support for PHP versions will be offered until there's justifiable reason to drop support for an older PHP version.
- Support for a PHP version can only be dropped at least 1 year after it's security release has ended, provided justifiable reason has been provided.
There was a problem hiding this comment.
What would be a justifiable reason?
There was a problem hiding this comment.
we could just have no formal policy on php version support. ;)
Sure, we could, but ...
and do the sensible thing on applicable branches
...we could also repeat discussing this every other week, month, or year until we lose interest contributing and eventually abandon this package - but: I'm not getting paid for this, and neither are any of you.
The sensible thing to do for all of us is to avoid wasting resources.
A clear, actionable PHP version support policy can help us with that.
There was a problem hiding this comment.
I understand and appreciate that we can all change our minds, but see #3 (comment):
I am personally not happy with supporting super old PHP versions. I think 7.1 makes for a good lower-bound in 2020. People using deprecated PHP can still use the 1.9.1 release. My view is that if you are happy to use super old PHP, then using an old version of a library comes with the territory.
localheinz
force-pushed
the
feature/php-version-support-policy
branch
from
ac0dd7f to
0a0a82e
Compare
| @@ -99,6 +99,10 @@ return static function (Config\RectorConfig $rectorConfig): void { | |||
|
|
|||
| Faker is released under the MIT License. See [`LICENSE`](LICENSE) for details. | |||
|
|
|||
| ## PHP Version Support Policy | |||
|
|
|||
| The maintainers of this package add support for a PHP version following its initial release and drop support for a PHP version one year after it has reached its end of security support. | |||
There was a problem hiding this comment.
I'd rather make this 2 or 3 years.
There was a problem hiding this comment.
I like this a lot. Having a clear understand amonst everybody what versions of Faker support what PHP versions are is good. By dropping support for older versions of PHP, we are not blocking people from using Faker. They will just be stuck on a slightly older version, probably like most of their dependencies.
|
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). 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.. |
|
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.
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.
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 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 |
|
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. |
|
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
force-pushed
the
feature/php-version-support-policy
branch
from
0a0a82e to
851bc7c
Compare
|
Can we merge this, I think we've reached a majority of people agreeing, right? |
|
I think all we need here are a few approvals to move forward! |
What is the reason for this PR?
Related to #747.
💁♂️ Also see https://localheinz.com/articles/2023/09/12/adopting-a-reasonable-php-version-support-policy/.
Author's checklist
Summary of changes
Review checklist
CHANGELOG.md