On Jan 9, 2018, at 12:36 PM, Bill Cole <macportsusers-20171...@billmail.scconsult.com> wrote: >> On Jan 8, 2018, at 9:46 PM, Bill Cole >> <macportsusers-20171...@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
