http://www.perlmonks.org?node_id=640264


in reply to The need and the price of running on old versions of Perl

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.

Replies are listed 'Best First'.
Re^2: The need and the price of running on old versions of Perl
by papidave (Pilgrim) on Sep 21, 2007 at 13:26 UTC
    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).

    This is a simple, yet tremendously profound comment. For many organizations, upgrading language tools is a hairy business -- hence the reason I have to support compilers for the thirty-year-old F77 standard. Today, I have systems in production that run perl 5.005, 5.6.0, and (several variants of) 5.8.x. I'm hopefully eliminating the two older of these versions, real soon now (TM) -- but I expect the 5.8 tree will be around for some time. This is primarily because 5.8 is "current" for the OS versions I am using, and getting approval from the software police requires approval from God, Congress, and Griffin (the mythical creature, not that guy in finance :)).

    I am primarily a module user, and all the modules I write are for internal use only -- but I know the pain of trying to code for a perl rev that doesn't support 3-arg open() or function prototypes. Occasionally, that situation forces me to defer code reuse and roll my own because I can't find a compatible version of the .pm I want.

    Based on this experience, I can completely understand why module writers don't want to be burdened by trying to get their code working under older Perl revs. I am also extremely grateful to those of you who do.