p>In this article I'm going to explain some of the problems I face when upgrading libraries, language interpreters and other pieces of software which power the web applications I use in production. I'll then be showing how Perl, Catalyst, DBIx::Class and many of the other CPAN modules I use cleverly solve most of these issues.

The issues with software upgrades

When choosing the instruments for building a new web application (or a software in general), a programmer usually bases his decisions on aspects such as knowledge of the language, availability of needed libraries, speed of development, speed of compiled code, and a few others. There is however an important aspect which often doesn't get properly evaluated, which basically is the answer to the question: what is going to happen to my application in 5 years or so?.

IMG_0563

This question actually needs to be broken down in at least four parts:

  1. What is going to happen when a new version of the language (interpreter, compiler) I use will be released?
  2. What is going to happen when a new version of the framework/libraries I use will be released?
  3. What is going to happen when the server where the application is gets updated?
  4. Do I really need to update libraries/language/system/other software?

Minor releases of language interpreters or compilers (question 1) don't usually feature incompatible changes: if they do, that's probably a bug. Major releases, instead, could. For instance, PHP 5 had some incompatible changes when compared to PHP 4 (even though they were just a few). You're not forced to upgrade, but you might actually want to: a configuration option (an instruction at the top of the source code or so) which enables or disables old behaviour could be desirable for situation such as this.

New versions of libraries/modules/frameworks (question 2) sometimes bring incompatible changes, mainly due to deprecation of features: you can't always support legacy things, it's a fact. It's however important to have a good deprecation -> removal cycle for features: this allows users of a library to get warned much beforehand so they have plenty of time to patch their software, and can decide when to do it. Since libraries are developed by a lot of different people, this aspect is covered better or worse depending on the developer.

If you are hosted in a data center in a managed server (which sometimes gets upgraded even if you don't ask for it), or if you decide it's time to update your old system, then you need an answer for question 3. It is basically a sum of 1 and 2, adding some more possible incompatibilities with system tools, etc. You should choose a provider which notifies you months ahead of possible big upgrades to their systems.

So, should you upgrade (question 4)? My opinion is yes, you should do your best to have an up to date system of stable, distribution quality, software, because you're likely to get the latest security patches and the best performance. However, there's no reason to hurry an upgrade, except for serious security issues: take your time, a rushed upgrade is much worse than leaving a working system as is.

The (smart) solutions with Catalyst and Perl

I have some applications in Perl which use Catalyst in production since 2007 or so: Perl was upgraded several times (from version 5.8.8 up to 5.16.1 as of today); libraries were upgraded countless times; operating system was updated regularly. After all of this, the application still works almost no change in 5 years!

First of all, the main libraries I use (Catalyst and DBIx::Class, plus some Catalyst plugins and tenths of other CPAN modules) have an outstanding deprecation policy, which allows me to know way beforehand what API features get removed or changed; also, the code modifications I needed to make were always small enough not to be a real issue.

Perl 5 itself does a pretty good job when it comes to maintain backwards compatibility. When a new major release comes out (i.e. 5.14 => 5.16), backwards compatibility is the default, as you have to specifically enable new features with something like:

use v5.12;

# And it's scoped lexically, so you can
# upgrade PARTS of your software
sub mysub {
    use v5.14;
    ...
    {
        use v5.16;
        ...
    }
}

Thanks to these clever features, which actually solve most of the issue for you, upgrading the software underneath your application while having the application still works (with the added benefits of the upgrade, too!) become a much smaller problem. Just to say an example, I recently upgraded a server with a Catalyst application from perl 5.14.2 to 5.16.1: this involved the reinstallation of some 476 CPAN modules after the upgrade; when it was finished, the application was restarted and it continued to run exactly the same as before, without a single change made.

Also, if you feel you don't want to update your perl interpreter when the operating system gets update, you're not forced to use the perl bundled with the system: take a look at perlbrew, and you'll have your own interpreter in your user directory (you don't even need root access to compile and install it), fully independent and fully managed by you.

Summing it all up, Perl and its ecosystem are proving to be very trustable, and this in turn makes applications very trustable as well, with all the derived benefits!