Alright, 140 characters are a bit too few to discuss this topic, so here it goes.

Please take a look at the twitter post that started it and mst’s excellent post for context.



Software doesn’t exist in isolation. Even non-embedded computer systems not connected to the internet affect their environment. A computer running the same software for 10 years might not have changed and for all appearances it might be running perfectly, quietly performing a task it’s been setup to do and then half-forgotten. We all know stories about a server we could ping, but couldn’t physically locate because noone needed to for years.

I think that idea is way too romantic. The computer or it’s task might not have changed, however the ecosystem around it did. One of the most important aspects of that ecosystem is the security perspective.

10+ year old, unmaintained software is utterly insecure. Perl’s security record is better than most projects’, but even then it isn’t perfect. I’m too lazy/short on time to find exactly how many issues exist in perl 5.6.x and it’s core modules that were never patched with a point release, however I’m guessing it’s non-zero.

One area that has been pretty hard for open-source projects is the matter of defaults. It takes real effort to provide sensible defaults, even in security sensitive contexts (just look at the default TLS configuration for popular webservers, even in recently released versions they are pretty abysmal), or to know when to offer a TIMTOWDY choice.

On a very basic level, there is the open-source licence that entitles a user to use the source code in whatever way as long as it conforms to the licence terms, however that’s just the legal part - the law should always be a last resort, the smallest common denominator. There is a whole range of behaviours between “legal, but pretty fucking stupid, eww” and “legal, a shining example of recommended usage”.

Just as I think that an open-source project should provide sensible defaults as one of it’s highest priorities, I also think that there should be at least something approaching consensus and some clear recommendations on the lifecycle of software releases that’s consistent across the toolchain. Just to give an example, it might be along the lines of:



please beta test dev/bleed releases of perl if you can and you’re willing to take the risk of some bugs

please strive to run the latest stable point release and have an upgrade plan/deployment procedure in place for your systems

please keep in mind that only the n most recent stable releases get security updates, so it’s recommended that you stay within that range of releases

please keep in mind that toolchain is allowed to use new Perl syntax/features n years after they’ve been introduced in a stable release (where I’d prefer n=10) and running a perl version older than that is highly insecure, unsupported and you’re urged to upgrade immediately.

I think a lot of people think install-and-forget is okay or at least that it’s not bad. But that’s not true. Devices with software in them, especially when connected to the internet require updates. We’re heading toward a world of hurt currently as this is disregarded when designing smartphones, routers, IoT devices.

Specifically, when I said on twitter that maintaining compatibility with perl 5.6 is wrong, I meant not only that people shouldn’t try to maintain compatibility, but that it should be made explicit with a ‘use 5.008;’ line. This is not about breaking working code, it’s about acknowledging that 5.6 has been broken for a long while now and making that fact explicit.



I think framing the issue as a debate about backwards compatibility contains questions and arguments from another, slightly separate discussion. Deprecating 5.6 (and old software releases in general) is not primarily a backwards compatibility issue, it’s a software lifecycle discussion. I’m not suggesting introducing features to a new perl release that’s incompatible with old perl versions, but rather:

toolchain shouldn’t be anchored to ancient Perl syntax and releases, it should be allowed to follow perl development (with admittedly a huge time lag)

there should be a point with ancient-enough releases that the community decides they are old enough, insecure enough, buggy enough that we move past them, regardless of the effort it would take to keep toolchain compatible with those releases.

MST says that an argument against supporting perl 5.6 is “well everybody should have a recent perl and a working compiler”, but what I’m arguing for is an attitude change from indifference about ancient perl versions to one where it’s frowned upon. In this context, ancient for me is <= 5.6.3, recent would be >=5.20.x, outdated >=5.8.x and <= 5.10.x, and the releases between 5.12.x and 5.18.x neither recent nor horrible.



So for me, it’s “well everybody doesn’t need to be up-to-date, but having an ancient installation isn’t supported by toolchain and is frowned upon”.

Toolchain maintainers could support 5.6. They could allow other people to support 5.6, but I don’t think they should. It’s not about the effort or TIMTOWDY, it’s about the idea that software requires maintenance.

Some people can’t upgrade from 5.6 (I don’t think anyone voluntarily still uses it), which is just another way of saying that they don’t want to. They don’t want to, because they think it’s too expensive, because the original author of the inhouse Perl code left 5 years ago, because they don’t see the need, etc.

“Officially” deprecating 5.6 would go some ways towards underlining the need. Is it too expensive/inconvenient to update an old Perl codebase or you can’t find anyone to do it? Switch to Python/Ruby/Haskell/Rust/etc and hire someone to do it cheaper. I’d much prefer a recent, maintained codebase in language-not-Perl to an ancient-unmaintained-Perl codebase. Wouldn’t you? You can’t spare the expense to do either? I’m sorry, but software requires maintenance. Please try not to expose your outdated systems to the internet or at least be aware that your system is the equivalent of a fire hazard in a city.

I should add that I don’t mean to pontificate from a hill. I haven’t been involved in Perl development that much in recent years and even before that the most I can say is that I’ve been a p5p reader. Raising some points for discussion is about the most I can do at the moment.

I’ve joined the discussion for the simple reason that software updates, defaults, ecosystems and security have been on my mind (or at least the back of) for a few years now and I despair at the general state of things.

I also have questions, I’d be interested to hear from people who care about 5.6 compatibility. WHY? Is there a reason that didn’t come up in this discussion yet?

I’d also love to hear about deprecation policies in other open source projects and programming languages.

