I suspect that people's opinions on this debate are highly correlated with whether or not they have worked in an environment where they were forced to use an older version of Perl (or other similar package). The attempts to get newer things working on such machines leave scars that go very, very deep...

There are many very good reasons why different organizations may need to use older versions of Perl, and yet still need newer modules. This fact in no way makes module authors responsible for supporting older versions, although I would hope that it's enough to make us accept nonintrusive patches to provide such support.

The way I look at it is that if you're putting a module out there, you are doing it to help people. Maybe that's not your primary concern; that might be the ego gratification or whatever, but you don't get any of the other benefits without actually helping people. So the question of maintaining backwards compatibility is strongly influenced by your estimate of the number of people such support would help. For example, a module in a ton of other modules' dependency trees has much more motivation to provide backwards compatibility than a leaf module.

My personal approach is to try to maintain backwards compatibility, up to the point where using a new feature would make the coding appreciably easier or better. When that happens, I discard support for older versions lacking that feature without a backward glance. Thus, I could say that I only break backwards compatibility when there's a decent reason for it, but in truth, the reason doesn't have to be that good. If more people used one of my modules, though, I would worry a lot more.

I'd also like to point out Python as a counterexample. I tend to work with somewhat but not excessively old Linux distributions, and I've lost track of the number of times I've run into "application A needs python 2.2 but also library L which I have for 2.2 but I also need for application B, which requires a newer version of library L that requires and installs into python 2.3's tree". For whatever reason, I am constantly fighting version dependency battles with Python, and rarely am with Perl. Some of that is because Perl makes it relatively easy to support older versions -- even when a major release is technically not API compatible, Perl tends to minimize the API changes to the extent that very little code actually breaks.

In reply to Re: The need and the price of running on old versions of Perl by sfink
in thread The need and the price of running on old versions of Perl by szabgab

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.