When you’re paying attention to the Perl news about new Perl releases, you need to know which ones matter to you. It seems like a simple question, but there are many things to consider. Do you use an experimental or stable release? In a stable release, which of the supported versions should you use? What does your vendor provide? What does your manager let you use?
Experimental versions
There are two tracks of perl development: an experimental track and a maintenance track.
To tell the difference, you need to know a little about the perl version numbers. The version numbers come in three parts: the major, minor, and point releases,and it’s written major.minor.point, such as perl-5.12.1. The major version of perl is 5, and people often just drop the “5” when talking about the current major version. Since Perl 5 has been the major version for over 15 years, the minor version isn’t as minor as you would think. It’s now the main releases, that happen about once a year.
The experimental track releases versions with an odd number as the minor version, such as perl-5.11.x and perl-5.13.x. Unless you are developing perl or testing your code with the possible future versions of perl, you don’t want to use the experimental versions. You should probably never install these on production servers or expect them to even work. Each minor release in the experimental track can be much different than the previous minor release. That’s why they are experimental.
If you want to test your current code with an experimental version of perl, you can use the instructions in Compile your own development perl. This gets you a bit of extra time to convert your code to a future version of Perl.
Maintenance versions
The maintenance track has an even number in the minor version, such as perl-5.10.x and perl-5.12.x. These are often called the “stable” versions, and they mostly are stable. They are highly tested (or “smoked”) across many operating systems and versions of CPAN modules. However, they usually have new features that people have not used extensively. Some of these features might also be labeled as “experimental” because they might not stay in perl. There have been some features, such as pseudohashes, that were bad enough ideas that the developers removed them from the language.
Which one of these do you choose? The na�ve advice tells you to always choose the latest stable version. The latest must be the best, right? There are some more things to consider, and some of them might mean more or less to you than they do for other people. You have to judge for yourself how important these are.
The supported releases
By policy, the perl developers support the last two stable versions. They might release maintenance releases of older versions, but they don’t feel any obligation to do so. If the latest stable version is Perl 5.12, the developers support 5.12 and 5.10. That means that Perl 5.8, perhaps the most widely installed, is unofficially unsupported.
If you are using Perl 5.12 when the developers release Perl 5.14, you are still using a supported version, but should you upgrade to the latest supported release? Since these releases now happen about once a year, what’s your tolerance for an upgrade cycle? If you have good end-to-end tests in place and you have good confidence in those tests, you might feel confident about testing and deploying a new perl and introducing the new features that that perl provides. If you don’t have a good way to test your code, the new perl might introduce problems that you don’t have a way to diagnose.
A new perl isn’t just perl, it’s new versions of all the core modules, some of which might change how your code works. That might also mean you have to update CPAN modules because the latest core modules break the old CPAN versions.
Even with good tests, how often do you want to distract yourself from new development to integrate a new version of perl? Some people like doing that frequently, and some people despise it. You have to decide to which side that you are closer.
Unless you are dealing with legacy code, stay away from the unsupported releases if you can. Some vendor packages only supply unsupported Perl versions. If you are stuck with only what the vendor provides, well, sometimes life sucks.
So, which of the supported releases do you choose?
The latest stable release
The latest stable version, such as perl-5.12.1, is also necessarily the one with the fewest users (counting only the supported ones). They are the ones that need updates in the different vendor packages (see Choose the right Perl distribution for you). You can always compile your own, but you might have to wait longer to get a vendor package.
Since fewer people use the latest version, there’s a smaller pool of people you can ask for help. That might not matter, though, since it’s usually the same people answering your questions no matter which version you’re using.
The answer to this question depends on how much you want to think about supporting Perl. The newer the stuff you want to install, the more you have to rely on yourself. You might be the first person to discover a problem. With older releases, other people have probably run into the problems already and the answers might already be out there. The chances of you discovering a new problem are much lower (but not zero!).
The .0 releases
The .0 point releases, such as perl-5.12.0, should really be an (dis)honorary experimental release since it is the first release that most of the Perl users will ever try. If you are adventurous, this might be for you, but don’t get rid of your old perl.
Once the .0 release gets out, people start using it and noticing problems. The development versions had very few people reviewing it and commenting on the new features and designs. Once it becomes stable and people start deploying it, many people with a fresh perspective start noticing odd things. For instance, smart matching was so broken in perl-5.10.0 that they had to change it in incompatible ways for perl-5.10.1.
Not only that, people still have to try the latest versions of Perl with the various modules on CPAN. The CPAN Testers already do a pretty good job checking this with the experimental versions (Item 97. Use CPAN Testers as your QA team), and the developers do a good job to update the important Perl modules before the next stable release gets to the public.
If you aren’t so brave, you probably don’t want to deploy a .0 release. Test your code with it, but don’t commit to it until you see what the general experience turns out to be. Otherwise, you’re just one of the human trials for the new drugs.
Things to remember
- The experimental versions have odd numbers as the minor version, such as perl-5.13.2.
- The stable versions have even numbers as the minor version, such as perl-5.12.1.
- The perl developers support the last two stable versions, such as perl-5.10.x and perl-5.12.x.
- The .0 releases still might have problems, so they are semi-stable.
- The latest minor release has the fewest users of the supported versions.