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>