PHP version retirement

[Franco Fichtner]

> On 12. Aug 2019, at 00:22, Adam Weinberger <adamw at adamw.org> wrote:
> 
>> 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

I don’t believe this is anywhere near true for two reasons: FreeBSD ports does not add as much maintainers as it says it desperately needs so you are creating a scarce environment to base your „too much work“ argument on. The other part is having handled a ports fork myself since 2015 the work to keep a port where it is is low at its worst.

>> 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.

Well, you are arguing against a grace period for obsolete software which is quite pointless because the software is not bad per se. It will be eventually and it should be removed and nobody argued against that.

In the case of PHP 5.6 a clear error of judgement was made based on a reasonable decision at the time. It should give enough incentive to not let this happen again so quickly and try to learn from how it negatively impacts users.

I‘m going to reiterate because nobody acknowledges the obvious: 1,5 months mean of a grace period in quarterly is productions worst enemy, not to mention when you run HEAD.

> 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.

That makes no sense for PHP ports which are part of the picture here. But you probably know that. :)


Cheers,
Franco