PHP version retirement

[Adam Weinberger]

On Sun, Aug 11, 2019 at 1:05 PM Franco Fichtner <franco at lastsummer.de> wrote:
>
> Quarterly is essentially useless if the decision is to immediately axe a deprecated release. 3 months are nothing in production environments, if you get 3 months (1,5 months mean) at all and also all other updates and security relevant bug fixes in the same quarterly that you desperately need.
>
> Yeah, we know that won’t happen so please don’t suggest it.
>
> That deprecation policy is nice and well all by itself except when it wreaks havoc over the ports infrastructure like in the case of PHP version support where numerous ports are immediately unavailable and incompatible with upgrades.
>
> Furthermore, the argument that it is more more work to maintain an abandoned version is silly because it’s more work to delete a port that to just keep it in the tree for a while longer.

That last part isn't correct. The work of deleting the ports is
largely automated and simple, and it will always happen eventually.
The work involved is in supporting unsupported versions. Our php team
is spread very thin, and they simply cannot support php versions
outside of upstream development. There are no resources to backport
fixes that may or may not be designed to work with older versions

> That „while“ is debatable, but it’s neither indefinitely nor immediately. The people responsible for FreeBSD ports and packages would be wise to enrich their policies with a more graceful way of dealing with legacy software, especially if it relates to more than a handful of ports in a single deprecation decision.
>
> TL;DR: don’t remove PHP ports prematurely and you’ll have less work reading mails like these.

Part of the contract in providing packages includes providing support
for them. Other OSes provide packages for software that they can never
support, and there are definitely consequences for that paradigm. This
is doubly true for PHP, which is extremely common and for which
security fixes can be vitally important.

I've been thinking about this a lot lately (I used to be hardline
against it), but at this point I am not fundamentally opposed to the
idea of providing old versions of major languages and interpreters, as
long as (a) they cannot be specified by DEFAULT_VERSIONS, (b) nothing
can ever depend on them, and (c) it is clear that they are provided
without support and at your own peril.

# Adam


-- 
Adam Weinberger
adamw at adamw.org
https://www.adamw.org