Recently on the perl5-porters list, there have been several discussions about backwards compatibility and the future of Perl 5.
Jesse’s plan is interesting, and in theory sounds like a good idea. Unfortunately, it brings up some incredibly thorny issues and may not be technically possible. Even if it is possible, it’s likely that lexically preserving backwards compatibility will not work for every proposed feature.
This is an old discussion. The p5p list has been debating backwards compatibility versus evolution for years.
One thing that keeps coming up is that backwards compatibility is important for people who are using their system-installed Perl. If they upgrade from RHEL 5 to 6, they’ll move from Perl 5.8.8 to 5.10.1, and they can’t really avoid that. People who are stuck in this situation are very concerned about backwards compatibility.
I’m not very sympathetic to this view. You have an uncontrolled dependency in your system, and you expect the maintainers of said dependency to essentially keep your code working for free. But my sympathy is irrelevant, because I’m not in charge. I don’t think p5p as whole (or Jesse as a one) will ever tell these users to just deal with breakage.
All of this leads up to the title of this entry. Why do people use the system Perl? Well, answer number one is that it’s really convenient. Perl is already there, so why not use it?
If we can make it easier to not use the system Perl, maybe we’ll feel a little freer to (very slowly) break backwards compatibility. We already have perlbrew, which is a great tool for development, especially when you need to test code with more than one version of Perl.
I’ve seen some people suggest that somehow perlbrew can replace the system Perl for an application, but I don’t follow that logic. If I’m running an app across thirty servers, do you seriously expect me to run “perlbrew install perl-5.14.2” on each one? That’s nuts. Package systems were invented for a reason.
Wouldn’t it be cool if we (as a community) provided a set of “official perl.org” packages of Perl. After all, we’re programmers, and this is a task that’s ripe for automation. These packages would install under some location like “/opt/perl-5.14.2”. For each version, we might provide both threaded and non-threaded versions.
Being able to keep a consistent Perl version across system upgrades will prevent the “I upgraded my OS and all my Perl code broke” problem. As a bonus, this might also make it easier for people to upgrade Perl more quickly if they want to. Not being tied to the system Perl is good for people who want stability and people who want to upgrade faster.
Putting this on perl.org and calling it official is an important part of this plan, since many sysadmins are rightly suspicious of random packages found on some random dude’s website.
What do people think?