-
Notifications
You must be signed in to change notification settings - Fork 337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix: Drop support for PHP 7.4 #733
Conversation
c212560
to
b31bce9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to retain PHP 7 support, to encourage people to migrate from the old package to this one. I also feel like this package should retain a wide range of supported PHP versions.
We already had this conversation before. Half of people installing the old package last month were using PHP 7, and still more than 10% on our new package. I know people can use an older version of this package, but often people are not very competent at choosing package versions, and I don't want to put up blockers. |
Please allow maintainers, contributors, and users to discuss proposed changes before closing pull requests you disagree with, @GrahamCampbell. |
I oppose this change in the strongest possible terms. It's so important that testing frameworks retain a large range of supported PHP versions. We already compromised by dropping PHP 7.2 and 7.3. If we drop 7.4 too, and PHP 8.3 or 8.4 make breaking changes, and we add new features, it may be impossible to test code on both PHP 7.4 and 8.3/8.4 without a mess to support two different versions of faker. We've already seen how much a mess this was with PHPUnit - Symfony's simple phpunit should not have been necessary. |
Feel like I have to agree with Graham here, it's good for dev dependencies to have a less strict restriction on PHP versions. Looking at the data; a not insignificant amount of downloads still come from <8.0, so as long as it's not a maintenance issue for us to support 7.4, let's keep it around. That being said, let's indeed not close pull requests or issues without chance for a discussion. |
b31bce9
to
11db58e
Compare
Reasons for that percentage to go up
Reasons for that percentage to go down
If we drop support for PHP 7.4, we do not need to run tests for By dropping support for PHP 7.4, we - like everyone else who drops support for outdated PHP versions from their PHP packages, increase the pressure on application maintainers to update from outdated to supported PHP versions. This is a good thing.
These people can still install older versions of GenerallyIt probably makes sense to adopt a general PHP version support policy for this package - for how long after the end of life of a PHP version do we want to support that PHP version? |
I'm with Graham here. I'm all in favor of maintainers pushing the ecosystem forward by reducing PHP supported version in their libraries if they want to. Testing library, however, is a major factor in version upgrades. We need to upgrade our codebase and trust our tests will catch breaking changes or issues that would otherwise become bugs in production. If production code is being touched, it can be desired to avoid modifying tests. If test code is being touched, it can be desired to avoid modifying production code. That increases confidence and helps with upgrades. Unless there's a relevant benefit for the package itself to upgrade, I'm inclined to think that forcing PHP upgrades on testing libraries causes more harm than good in the goal of getting projects to upgrade. |
The current version of |
Im not a favor of the drop though i would like to. It brings us not a single benefit dropping older versions and instead of breaking the 1.x branch i'd rather work om finalizing 2.x. If im correct the main topic there is migrating the existing locale and then we can even publish a first alfa already |
@bram-pkg @deleugpn @GrahamCampbell @pimjansen Can we agree to drop support for PHP 7.4 in |
I think if we have to change to type stuff we should yes. And from there on we can properly maintain it when we do not drag all the code ourself and a bunch of legacy |
@localheinz To me, a feature-complete library like Faker only needs code change to make itself compatible with future versions of PHP i.e. addressing breaking changes or syntax changes. Also, I like what Symfony does with their new major version which is an exact copy of the previous version minus deprecations-only. Tagging a 2.0 version where PHP 7.4 is no longer supported causes dependency-creep where updating a dependency forces the update of a PHP "Era" version (7.4 to 8.0). If PHP support needs to be dropped, perhaps allowing dependencies to gracefully handle package update first (2.0 with >=7.4) and PHP update second (2.1 with >=8.0) would make upgrade easier. Overall, dropping support for a PHP version just for the sake of dropping it on a core component of test suites across the PHP community will, in my opinion, cause more upgrade distress than help the community keep up-to-date, which sounds to me the opposite of what you would like to accomplish. |
That's an opinion, nothing more. We have dropped support for PHP 5.4, PHP 5.5, PHP 5.6, PHP 7.0, PHP 7.1, PHP 7.2, and PHP 7.3. Where were your complaints for dropping support for these PHP versions back then? Where were the complaints of users who were put under distress then?
Symfony is an open-source project. Unlike Symfony is also a commercial project. They want to maximize the number of users who use and lock in into the Symfony eco system. I maintain and contribute to this project (and many others) in my spare time. I have five sponsors. ![]() Symfony and
That's an opinion, nothing more. Where is your data? The maintainer of the applications and packages who you believe will be put in distress are outsourcing their distress to the maintainers of the packages that you believe will put them in distress when they drop support for PHP versions that have reached their end of life. As pointed out before on Twitter, there is no reason to be running PHP versions that have reached their end of life in production today, and consequently, there is no reason to support PHP versions that have reached their end of life as a package maintainer unless your goal is to maximize the number of users who use that package. Existing users who are unable or unwilling to upgrade to PHP 7.4 can continue using current or older versions of this package. As @GrahamCampbell pointed out, they are doing it. |
@localheinz hey man, I'm taking myself off this discussion and unsubscribing. You shared this thread on Twitter and asked for people's opinion. I came here to give you mine and now you're just escalating things. I know everything I said is my opinion. That's what I thought I was doing, sharing my opinion. But apparently you're not looking for people to give their opinion, you're looking for validation and support for your decision. I'm sorry I can't give you that. I'm running PHP 8.2 on all my production applications. If this library drops support for PHP 7.4, 8.0 and 8.1 today I won't lose one second of my life worrying about it. Good luck to everyone involved. I hope the decision that makes the best impact on the PHP community is made, regardless of what that decision is. |
Im not looking for opinions. I am looking for arguments for or against dropping support for PHP 7.4. |
Closing in favour of focussing on Also see #747. |
What is the reason for this PR?
πββοΈ PHP 7.4 reached its end of life on November 28, 2022.
Author's checklist
Summary of changes
Review checklist