in reply to Is there a concerted effort to break CPAN for older perl versions to drive support for v7?

I am surprised in the Perl community how common it is to run out of date versions of Perl.

Correct me if I'm wrong, but it seems to me that any version of perl prior to 5.30.3 is insecure (in that it would have unpatched CVE's).

Anyone using Perl for any semi-serious purpose should have tests in there release chain to assist in upgrading to the newest version of Perl at a moments notice - as a new version of a CVE could be discovered at any time.

Perl itself (at least for 5.x) is meant to be backwards compatible as well. I can't remember the last time I moved perl up and had a single compatibility issue even with my products using hundreds and hundreds of CPAN modules. I believe the last time was around 5.16'ish when Perl arguably broke backwards compatibility by changing some behaviors of the Perl API which impacted AnyEvent.

  • Comment on Re: Is there a concerted effort to break CPAN for older perl versions to drive support for v7?

Replies are listed 'Best First'.
Re^2: Is there a concerted effort to break CPAN for older perl versions to drive support for v7?
by hippo (Archbishop) on Jan 23, 2023 at 10:38 UTC
    Correct me if I'm wrong, but it seems to me that any version of perl prior to 5.30.3 is insecure (in that it would have unpatched CVE's).

    Yes and no. If you are installing it yourself from source, then yes. OTOH, I expect that most users will install from their distro's packages and these do get backported fixes while the distro itself is still supported. Thus you will see updates for example for the Perl v5.16.3 which shipped with CentOS 7 still being provided. So long as your distro is still shipping updates you can consider your old Perl to be safely usable.

    I can't remember the last time I moved perl up and had a single compatibility issue even with my products using hundreds and hundreds of CPAN modules.

    The 2 recent(ish) big breaks for me were the removal in 5.18 of '.' from @INC and the breakage in 5.14 of for my $i qw/foo bar/ { print "$i\n"; }. The former was well advertised, had a good rationale and an easy workaround if required. The latter less so.


    🦛