search

php-imagine / Imagine

PHP Object Oriented image manipulation library
https://imagine.readthedocs.io
Other
4.42k stars 529 forks source link

Drop php support below 5.6? #527

Closed burzum closed 3 years ago

burzum commented 7 years ago

Just see http://php.net/supported-versions.php

mbabker commented 3 years ago

No. It's a burden for every potential contributor to this library, as ultimately they too will need to take on those burdens for every possible code change (if writing a feature, they have to ensure it works with PHP 5.3 or has appropriate version guards, they have to write tests compatible with PHPUnit 4.8 or use appropriate version conditionals to make sure tests don't break on different version combinations). Unless you're basically saying "I don't care how people contribute to this library and they only write code which will execute correctly on PHP 7.4+, I'll do the heavy lifting to deal with version compatibility myself". Which, while applaudable, I would seriously say isn't worth the effort when you have real data saying that there isn't a real need for a new version of the Imagine library released in 2021 to support PHP 5.3.

ausi commented 3 years ago

Just as a side note: none of the open pull requests seem to have an issue with the PHP 5 support: https://github.com/avalanche123/Imagine/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc

mbabker commented 3 years ago

Well, then dead serious, if the consensus from those maintaining the library is "we are not changing the minimum supported PHP version", then this issue should be closed. As long as it remains open, it's just going to keep inviting discussion.

I only chimed in here because I saw the issue open, and thought I could provide new feedback beyond an emotional "old PHP is dead, stop supporting it" standpoint that a lot of people like to lean on by providing real-life usage data to show that supporting old PHP versions is (IMO) an unjustified maintenance burden as the numbers just aren't there for it. I've done OSS for the last decade and I have no problem justifying legacy PHP version support if there is an actual userbase for it. But, with the install numbers of this package from Packagist suggesting that the overwhelming majority of Composer users (which also seems to be the only officially supported install mechanism, there is zero documentation on setup and install without it) aren't using Imagine 1.* with PHP 5, I would conclude that even if you're comfortable supporting PHP 5.3 and even if those contributing to this library aren't blocked by the PHP 5.3 requirement, that there is just nobody using the current version of this library and a version of PHP which has been out of support since 2014.

PHPGangsta commented 3 years ago

Please drop support of old PHP versions 1 or 2 years after EOL. If you support old PHP versions, you are implicitly telling developers that you are OK with using those old versions. You shouldn't use or support old PHP versions years after EOL, be an example to others.

Libraries like Imagine should encourage users to upgrade their PHP versions every few years. People then still can decide if they stay with an old version of Imagine, or if they upgrade PHP to get the newest features, performance improvements and bugfixes.

A soft push from libraries helps the PHP ecosystem to move forward. (even Wordpress has 5.6 as Minimum, you shouldn't be behind Wordpress 😄 )

mlocati commented 3 years ago

Who am I to force someone to do something?

garak commented 3 years ago

Who am I to force someone to do something?

But, again, by dropping unsupported PHP versions you're not forcing anyone to anything.

mlocati commented 3 years ago

by dropping unsupported PHP versions

By dropping support for old PHP versions we'd force users to either stuck with an old Imagine version or to upgrade their PHP version.

garak commented 3 years ago

by dropping unsupported PHP versions

By dropping support for old PHP versions we'd force users to either stuck with an old Imagine version or to upgrade their PHP version.

This is not necessarily true. You can always maintain two branches of a library.

mlocati commented 3 years ago

You can always maintain two branches of a library.

I can barely maintain one...

robfrawley commented 2 years ago

Who am I to force someone to do something? -@mlocati

Do you believe airplane pilots should fly while taking drugs and drinking, or that online payment processors handling credit card numbers should have no restrictions on the storage of such sensitive information, or that companies can create an intentionally unsafe working environment for their employees?

Assuming you answered "no" to these questions, you agree with the majority of modern societies, where people are regularly "forced" (through legislative, regulatory, and social pressures) to operate in certain ways such that the overall health of said societies are sustained.

When you ask "who am I to force someone to [not run an end of life version of PHP]," I respond by asserting my belief that any reasonable steward of an open-source project understands they carry some level of responsibility for what they release, such as stability and security. Now, sometimes bugs make their way into a release, but I would not respect someone who did so intentionally. Now, in this situation, you are essentially supporting, if not outright facilitating, the use of your library on EOL PHP releases that are not only a security risk to whoever created or maintains the application consuming this library, but also to every single unassuming user who unwittingly uses it without knowing it runs on an outdated and unsupported PHP runtime.

I believe that is an irresponsible use of the power you weild as a library maintainer. I am of the opinion that the responsibility of maintaining an OSS project includes minimizing the potential avenues for misuse, whether intentional or not. Here, you have great leverage over ensuring your library isn't used on a PHP installation that is otherwise unsupported and insecure; use it. In the case of this specific library, due to the extremely low demand for EOL PHP releases (as detailed by @mbabker), you would not be forcing a large number of people to upgrade from EOL PHP anyway (other libraries have largely taken the bullet for you regarding this fight).

By dropping support for old PHP versions we'd force users to either stick with an old Imagine version or to upgrade their PHP version. -@mlocati

Correct, and most will choose to finally upgrade their PHP version once they need a new feature only offered by a new Imagine release, which is exactly what they should do since they are running EOL software that is a security risk to themselves and their users.

mlocati commented 2 years ago

you would not be forcing a large number of people to upgrade from EOL PHP anyway

I would force myself to do that: we use Imagine for a very old (and not publicly exposed) service. And I've been told to not touch it.

PowerKiKi commented 2 years ago

I've been told to not touch it

Then what would it change for you if newer releases don't support your old PHP version if you cannot touch your legacy system anyway ?

I feel there's often an irrational fear that "dropping PHP" will make it impossible to use the library with old PHP anymore. Of course that's not true, old versions of the lib will still be perfectly usable.

But more pragmatically, as of today the latest release of this lib is not compatible with PHP 8.1, even though it has been fixed and merged almost 6 months ago. There are a 9 issues that block a new release. And I spent a whole afternoon to create a PR that fixes 7/9 issues. And the way to fix those is to drop support for PHP 5.3 and 5.4, which are now over 10 years old.

So that is one very pragmatic benefit of dropping support for something that is almost no used at all: unblock the support for PHP 8.1.

You asked for what issues would be solved if we dropped some PHP versions, here are 7 of them:

PowerKiKi commented 2 years ago

FYI since https://github.com/php-imagine/Imagine/commit/e68f44578ec33d1bbd8d81ea9c0c7b3b6e83be48#diff-d2ab9925cad7eac58e0ff4cc0d251a937ecf49e4b6bf57f8b95aab76648a9d34L20 this project dropped support for PHP 5.3 and 5.4. It's a step in the right direction :tada: