[email protected] removal due to EOL

[SMillerDev]

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

https://secure.php.net/supported-versions.php

[fxcoudert]

I am all for removing unsupported versions, but [email protected] has 8,512 installs a month. Do we want to delay, or offer a migration path for users?

[SMillerDev]

We could delay but there won't be any security fixes and I'm not sure what kind of migration path would be possible.

[SMillerDev]

Let's group most most PHP changes with the 7.3 release on Thursday.

[fxcoudert]

Merged at the same time as #34869

[chrisdeeming]

Sorry guys but this is a bad idea, IMO. Right or wrong, we all have to still support customers who are using older versions of PHP, sometimes even have to ship software which has to support older versions of PHP.

Homebrew should have its own policy to decide when you no longer provide particular versions, even if it was something that had to be opted into behind some sort of flag, or display some fairly clear warnings.

The policy should, at minimum, continue to provide a non-supported version for 1-2 years beyond the official EOL period, IMO.

At the end of the day, it doesn't hurt or cost Homebrew anything to continue to provide those formulas, so removing these as soon as they become EOL seems kind of arbitrary (and a bit bullish IMO).

[SMillerDev]

The homebrew versioning rules say that versions are supported as long as there's active security updates. https://docs.brew.sh/Versions. This is no longer the case for php 7.0 so it's removed.

There's always an option to keep supporting older versions in your own tap but there's simply a maintenance burden for every formula and an even bigger one for versioned formulae. And that burden wouldn't be shared with upstream if homebrew would simply keep maintaining every version that's still possibly used.

[gjuric]

If the formulas still works what is the point of removing it? Once they stop working and it becomes a burden remove it, until then I don't see the point.

[GauthierPLM]

Because last time people kept a language version for longer than it was officially supported, it gave us two version of Python (2.x and 3.x) with version 2.7 still here after 10 years of Python 3.

This is the reason PHP choose to have a more aggressive versioning and EOL policy, and I really think package managers (whether it's brew or another one) should respect it. If every package managers keep old versions "because it's still works", then we'll end up in the same situation as with Python. And Brew rules specify that this kind of situation must be avoided by deleting unmaintained formulas.

Anyone is free to make their own tap to support old version of PHP, but I agree that it's not a good idea to keep them in the main repository.

[ahinkle]

Gutsy move IMO for devs such as myself upgrading PHP 7.0 projects for clients. Perhaps a well visible message on installation about the EOL would suffice.

[chrisdeeming]

The policy is flawed, and there's clearly a lot of support to reconsider it.

I agree it is unreasonable to keep versions indefinitely, but while there is active demand for it (and we're talking in the tens of thousands of installs per month here, so hardly insignificant) it is totally nonsensical to apply that policy so strictly here.

I propose a more reasonable alternative.

• A PHP version should be marked as EOL and display a warning on install
• The version should be removed 12 months after the EOL date OR until...
• The "no more than 5 versions" rule applies.

Whether or not that is something you would consider, I don't know, but it's a starting point.

I think this change is going to present a significant headache for you from users who disagree with the removal. Especially as, presumably, you'll also be removing [email protected] at the end of the year too under the same criteria. That's even more significant than the removal of [email protected] IMO due to the significance of it being the final PHP 5 version.

[SMillerDev]

I don't think it's up to homebrew to gather information about the software you use. https://secure.php.net/supported-versions.php can be used to find how long your PHP version is supported.

If you want to keep using unsuported versions of software, nothing is stopping you. It'll just be a little more difficult then it was before.

As for comments on the policy, those can be made on the documentation in https://github.com/Homebrew/brew

[gjuric]

I really hope nobody is using homebrew to deploy production apps. We are talking about development machines. Current stable Debian distribution is being shipped with 7.0 and their team is in charge of backporting security fixes if something bad happens (since the PHP team is not maintaining it anymore), so there is probably a ton of developers that will still be deploying to PHP 7.0.

[MikeMcQuaid]

If you wish to keep your clients on a version of software that's not going to receive upstream security updates: I hope your lawyer has confirmed that your contracts with them mean you aren't liable to known security updates.

@SMillerDev has explained above and I agree: we have written policy for such things so this should not come as a surprise to anyone. Additionally, it's really easy to maintain this formula in your own tap if desired but we're not going to make it easy for you to do the wrong thing.