PHP version retirement

[Martin Waschbüsch]

> Am 10.08.2019 um 12:53 schrieb Carmel NY <carmel_ny at outlook.com>:
> 
> On Sat, 10 Aug 2019 10:17:44 +0200, Martin Waschbüsch stated:
>> Would it not be better to have, say, the last two versions before
>> current stable still in ports but with a huge disclaimer saying: use
>> at your own risk, etc.?
>> 
>> What do y'all think?
>> 
>> Martin
> 
> If I might be allowed to interpolate, I believe that continuing to
> expose obsolete versions of software in the 'ports' system is a bad
> Idea. It is enabling the use of software, that for one reason or
> another has been superseded by a newer and possibly safer or more
> mature version.

Following your argument, there should no longer be a port of e.g. gcc48 in the ports tree as that, too, is no longer supported upstream.
I am not saying old software should never be retired, but the end of upstream support as the *only* criteron for removal from ports tree does not sound like a good idea to me.

> Usually, when a version or application is going to be removed from the
> 'ports' system, it is duly noted well in advance. I would recommend
> that we set a hard number, say 6 months or one year at max before said
> software is removed. That should give even the most procrastinating
> user ample time to render his/her system ready for that inevitability.
> It they have not accomplished that with the set time frame, they
> probably were never serious about doing it.
> 
> Just my 2¢.
> 
> -- 
> Carmel


What happened here was:
A port was updated to the last release upstream was going to publish, and *very* shortly afterwards removed from ports because support ended with said release.
In the case of PHP 5.6 it was not even the last release. PHP 5.6 was removed from ports before the final upstream release.

I think that a fixed time *after* the last upstream release would have been a sensible solution.