This medal has two sides. You only look at the backward compat issues. A developer or maintainer can be seriously hindered in two ways:

The step you describe here is most likely a stepping stone to implementation of new features that are only possible in 5.12 and up.

If you depend on a module that works FINE on the current (old) perl and does not have a security issue, why do you expect the author of that module to support 13 year old perl builds? Seriously, you are just saying that this old perl is *more* important than current or upcoming builds. What would your argument be to someone complaining that this module does not work on perl-5.37.8 with the features it promotes?

There are numerous reasons to stick to old perls, as there are numerous reasons to require a minimum version in production environments (to me that is 5.014002), and there are also numerous reasons to draw a line and require a minimuum version just to be able to go forward and support the current state of affairs.

For me the coin mostly drops in supporting old perl versions as my modules are quite high in the CPAN river, but I won't rule out that someday, I will also raise the bar to make development easier.

One more addition: stating a minimum version to authors that test their distro on all supported versions means they also need access to that version. Not all developers have 500+ prebuilt perl versions available. Sometimes you can ignore the minimum version and just build with the version you have. Sometimes you cannot.

merged edited addition: If an author states a minimum version, it might be the lowest version he/she has access to for testing. You might get away with an older version, but the author cannot guarantee it. YMMV. Additionally, they author might find a feature compelling enough to require the version it was introduced in. The end-user that still wants to use their module might be able to rewrite those to something supported in the version they want to support (like $a = $b // $c → $a = defined $b ? $b : $c;)


Enjoy, Have FUN! H.Merijn

In reply to Re: Is there a concerted effort to break CPAN for older perl versions to drive support for v7? by Tux
in thread Is there a concerted effort to break CPAN for older perl versions to drive support for v7? by Anonymous Monk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.