Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Aug 2019 15:22:46 -0600
From:      Adam Weinberger <adamw@adamw.org>
To:        Franco Fichtner <franco@lastsummer.de>
Cc:        =?UTF-8?Q?Martin_Waschb=C3=BCsch?= <martin@waschbuesch.de>,  FreeBSD Ports <freebsd-ports@freebsd.org>
Subject:   Re: PHP version retirement
Message-ID:  <CAP7rwcjR8SYmeJJe9KrmZRJj7qQpnjQ6N8kaqrdpDSDB4cFH6g@mail.gmail.com>
In-Reply-To: <D7D5D66C-AD53-4F2E-95E5-F0131DBC82AA@lastsummer.de>
References:  <CF1F28D6-1072-4BE6-B124-A97DE43FA4E6@waschbuesch.de> <64faf143-bae3-378c-3ee2-b196c2ea4111@astart.com> <16731AF5-68E9-4E41-8D21-CF5917BE32A4@waschbuesch.de> <20190810231216.GA23293@lyxys.ka.sub.org> <CD11C7D8-DC57-4402-848C-06BBAD220D8B@waschbuesch.de> <D7D5D66C-AD53-4F2E-95E5-F0131DBC82AA@lastsummer.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 11, 2019 at 1:05 PM Franco Fichtner <franco@lastsummer.de> wrot=
e:
>
> 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 secur=
ity relevant bug fixes in the same quarterly that you desperately need.
>
> Yeah, we know that won=E2=80=99t happen so please don=E2=80=99t suggest i=
t.
>
> That deprecation policy is nice and well all by itself except when it wre=
aks havoc over the ports infrastructure like in the case of PHP version sup=
port where numerous ports are immediately unavailable and incompatible with=
 upgrades.
>
> Furthermore, the argument that it is more more work to maintain an abando=
ned version is silly because it=E2=80=99s more work to delete a port that t=
o 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 =E2=80=9Ewhile=E2=80=9C is debatable, but it=E2=80=99s neither indef=
initely nor immediately. The people responsible for FreeBSD ports and packa=
ges would be wise to enrich their policies with a more graceful way of deal=
ing with legacy software, especially if it relates to more than a handful o=
f ports in a single deprecation decision.
>
> TL;DR: don=E2=80=99t remove PHP ports prematurely and you=E2=80=99ll 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


--=20
Adam Weinberger
adamw@adamw.org
https://www.adamw.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAP7rwcjR8SYmeJJe9KrmZRJj7qQpnjQ6N8kaqrdpDSDB4cFH6g>