On Nov 3, 2013, at 5:44 PM, Clemens Lang <[email protected]> wrote: > To be honest, I don't know why we've ever diverged from this strategy. > We're in a habit of shipping the latest and greatest version of software > for most ports we have, sometimes even if breaks dependents (in which > case we try to fix the dependents or get upstream to fix them for us). > Maybe somebody who has seen the transition back then can comment on > that?
because the maintainer wanted to do it (I think one performance regression in one perl release was also mentioned on the mailing list). > We're in a similar situation for python (and will probably be for php, > mysql, ...), where we still allow users to install versions that have > run out of support (even security-related) years ago, but I fear that's > another can of worms we can open when the perl situation is resolved and > we've learned our share from doing so. We should remove the non-upstream-supported stuff everywhere, I think it's actually an active dis-service to users to help install software that's not getting security updates... > I'd advocate for keeping the subport magic, though – there *will* be a > perl 6 sooner or later, and not throwing away that might simplify this > transition a lot. It's probably safer to think of perl6 as a separate language (you can't use current perl5 CPAN modules in perl6). -- Daniel J. Luke +========================================================+ | *---------------- [email protected] ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
