What's the push to require the latest Perl?

[Daniel J. Luke]

On Jan 9, 2018, at 12:36 PM, Bill Cole <macportsusers-20171215 at billmail.scconsult.com> wrote:
>> On Jan 8, 2018, at 9:46 PM, Bill Cole <macportsusers-20171215 at billmail.scconsult.com> wrote:
>>> An issue with that is the fact that some amount of perl5 code in the wild (often including widely-used non-core modules) is broken with each major version. This is why upstream maintains 2 major versions at a time, releasing a new version every Spring. So if MacPorts supports just one version, it would need to be the older supported version for some months after the annual release.
>> 
>> We don't bend over backwards for compatibility with other ports, I don't see why we should treat perl specially in this case.
> 
> Seriously?

yes.

> There are multiple obsolete versions of Python and Ruby actively maintained in MacPorts many years after upstream EOL. PHP is a weirder case, with php4 still there plus php5 which is "replaced by" php53 (obsolete) and the main php port having sub-ports in all 4 maintained upstream branches as well as 4 others that are long dead. Then there are the C/C++ compilers and the databases...

the number of these cases is outnumbered by counter-examples. I believe in almost all of the above cases it was a mistake to try to support multiple versions anyway (it's the 'easy' answer for 'hard' upgrades but is really just punting the upgrade problem to some point in the future).

Python is 'special' since python3 isn't really compatible with python2 (so it would be wise to have a perl5 and a perl6 if perl6 ever becomes something people use).

> I'm not arguing for supporting every upstream EOL version of everything, or even ANY upstream EOL version of ANYTHING, but it's hardly "special" to support the 2 upstream-maintained versions of a language.

There's a lot of additional complexity in supporting multiple perls (along with supporting multiple versions of p5 ports that go with them). The project in general suffers from more things that would be good to do than people who are willing to do it. perl's backwards compatibility is good, so in my opinion, there's not a compelling use-case for supporting multiple versions of perl5.

Maybe that means we wait a little while after an upstream perl5 release so that upstream p5 ports that are actively maintained get fixed.

Anyway, I've argued this before and no one seems to like it - so we keep having to do the same work whenever there's a perl5 upstream release.

-- 
Daniel J. Luke