On Sun, Aug 11, 2019 at 1:05 PM Franco Fichtner <fra...@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 ad...@adamw.org https://www.adamw.org _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"