5

I'm have Perl 5.8 installed on all of our servers and wanted to use the DBI and DBD::Oracle modules to access our databases. My main concern is with the newer versions of perl the DBI and DBD modules will stop working with 5.8. Then I'd have to upgrade every server to the newest perl version.

My question is as perl itself becomes later versions and modules are developed for them will they still be backwards compatible? "CPAN does not carry all ancient releases and patchlevels of Perl", if I create documentation saying run "cpan -i DBI" if the newest version of DBI will not function with 5.8?

brian d foy
  • 129,424
  • 31
  • 207
  • 592
krizzo
  • 1,823
  • 5
  • 30
  • 52
  • Perl 5.8 is three major versions behind the current Perl 5 stable. I'd recommend upgrading, at least for your in-house software. You can use Perlbrew to install a more up to date perl without interfering with the system perl (which might be depended upon by system tools provided by your distro). – Quentin Jan 26 '12 at 23:19
  • "CPAN only supports the latest version of a module" -- this isn't true - you can download any older version of a module that is still hosted on the CPAN server (and it takes special effort to remove an older version from being distributed, so many authors never bother). If a distribution drops support for a particular perl version, you can request the module author(s) keep an older version up on CPAN to support legacy users. – Ether Jan 26 '12 at 23:28
  • You may also find this article of use: [Visualizing the Perl 5 support policy](http://www.dagolden.com/index.php/1605/visualizing-the-perl-5-support-policy/) – Ether Jan 26 '12 at 23:29
  • I wish there were more specific terms for backward compatibility. When I think of backward compatibility I think will newer distributions support older code. Python is the big offender with python3 not supporting python2. That’s not what you asked but this is the top Google result! – Sridhar Sarnobat Aug 21 '22 at 18:14

3 Answers3

9

There is no guarantee.

In general, you want to use the same versions of the modules on all your systems. If you use different versions then you will have different bugs and features available on different servers.

I'd suggest creating Debs / RPMS / etc for the ones you are going to use and then run a package repository that all your servers share.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • Yeah I agree the only way I was looking at installing the same version but it was talking about creating a mirror of CPAN in order to do it. Some of the servers are windows systems which is why I'd like to do a CPAN type install instead of creating packages. – krizzo Jan 26 '12 at 23:26
  • This is why I prefer static linking! – Sridhar Sarnobat Aug 21 '22 at 18:15
7

Not absolutely, but in general perl is pretty gentle about breaking code, with not many breaking changes, and long deprecation cycles on the ones that do happen. A pretty hefty portion of the code that was uploaded to CPAN in 1999 will run without modification in perl 5.14.

Since perl 5.12, the perl release cycle has become shorter, and the deprecation periods have also become shorter, which is cause for concern, but at the same time the concept of feature versioning has gained currency. The idea is that code may declare the version of perl that it's targeting with use VERSION (e.g. use 5.16.0), and any code that doesn't declare a version is assumed to be targeting approximately 5.10. When code that targets an older perl version is run on a newer perl version, newer features that might cause compatibility issues (e.g. new keywords) are disabled, and old misfeatures may be re-enabled in the name of compatibility. This isn't an absolute guarantee, but it will be adhered to as much as practical.

More information about back-compatibility and deprecation is in perlpolicy.

hobbs
  • 223,387
  • 19
  • 210
  • 288
6

In general, no. There are a lot of great new features in recent releases of Perl (smart match operator, the // operator, for two one example) that are not backwards compatible. Many authors will decide to take advantage of these features rather than keep their modules compatible with older versions of Perl.

Check the CPAN Tester's Matrix of a module, including the link about the max version that passes all of the distribution's tests, to get an idea of what versions of Perl are compatible with each version of a module.

cpan -i Some::Module will indeed attempt to install the latest version of the module Some::Module, but with a little research, it can be used to install older versions too. You need to find or guess the author of an older version and provide the path to the distribution on the CPAN mirror servers. For example,

cpan -i J/JF/JFRIEDL/Yahoo-Search-1.9.12.tar.gz

cpan -i A/AS/ASG/List-Gen-0.80.tar.gz

CPAN authors may delete their older distributions from CPAN. But even then, the distribution is available at the BackPAN if you're willing to download, unpack, and build the distribution yourself.

mob
  • 117,087
  • 18
  • 149
  • 283