RFC: Why Perl v5.20.2 is available for download and v5.18.2 is available on the LinuxOS repositories

[thanos1983]

Hello monks,

Today I was given the opportunity based on a really nice question on the forum Another 64-bit Perl bug. Is it fixed post 5.18? to read and found that strings longer than 2**31 bytes on 64-bits OS can only be processed in Perl v5.20.0 and afterwards, more information about that can be found here Better 64-bit support.

allowing Perl arrays to hold more than 2**31 elements, if you have the memory available

So my question is, since Perl v5.20.2 is a better and stable version, why the repositories still have the v5.18.2?

Thank you for your time and effort replying to my question in advance.

[aaron_baugher]

Updating software on repositories takes time. Packages have to be built and tested on various hardware, sometimes patches have to be applied, etc. Some operating systems also intentionally lag behind the latest versions a bit, to avoid picking up brand-new bugs or security issues. Tried-and-true versions generally require less frequent updates.

It's a fairly thankless task, so they might appreciate some help, if you want to volunteer.

[thanos1983]

Hello aaron_baugher,

You are right, I did not even thought about it. I thought that since a new version is released then automatically all repositories will fetch it and they will be updated. But you are right, they need to test it check if it will produce conflicts etc.

I would love to help, but for the moment I see my self as a beginner and not as an expert. Days go by, and I found my self more basic user than what I thought about it the day before. So many people here know so much, I need to continue working and learning more so maybe at the end I might be able to contribute.

Again thank you for your time and effort reading and replying to my question.

[davido]

There are many repositories, and even more reasons.

Consider CPAN, for example. That repository maintains a copy of just about every version of Perl, partially for historical value, but also so that authors of modules can access older Perl versions to verify compatibility of new code with old Perls.

perlbrew can install latest releases of all major versions from 5.20.2 back to 5.003_007. Again, this is useful to people trying to establish compatibility with older Perls, or trying to develop code that targets a production environment that still uses an older version.

Vendor repositories (CentOS, Redhat, Debian, etc.) may prefer stability over latest, at least for their production branches. And that being the case, they may prefer the devil they know over the devil they don't. Just as people are discouraged from upgrading system Perl because they may break system code that targets a given version, vendors are also reluctant to go through the process of regression testing all their established system code against a newer Perl version, and reluctant to force changes on their end users when those changes could have unforeseen consequences.

OS vendors have to balance the benefits of keeping their version of Perl up-to-date (bug fixes, security patches, etc), with the time costs and stability costs; the time it takes to build new rpm's, deb's, or whatever, the time it takes to test all system code that uses Perl, and the time it takes to support users who uncover code compatibility problems that the vendor could hardly anticipate. Time is a scarce resource.

And businesses that build their systems on Perl are also going to be fairly slow to upgrade their production-environment Perl for many of the same reasons. The possibility of something breaking with an upgrade is a strong deterrent. Especially if the production code base's regression test suite isn't comprehensive (as is often the case).

All this only scratches the surface. Everyone has their own reasons, even if the reason is only "don't fix what's currently working." Most Perl developers I know enjoy installing and using newer Perls in their own sandboxes; tinkering with new features, fantasizing over how their code would look saner if they could just use some new feature, and so on. But at the same time, they understand the reality that it's a lot easier to install a new Perl in a tinkering environment than in a dev/production environment. The Perl version being used in production is really a form of technical debt, after all.

[thanos1983]

Hello davido,

You are right, compatibility is way more important factor than having the latest version. Plus so many new bugs that can be introduced and produce so many problems due to this reason.

As you said it makes more sense to upgrade locally if needed instead of the repositories to have the latest version.

Thank you for your time and effort reading and replying to my question, it helped to understand a few things.

[sundialsvc4]

And there is yet-another reason:   core software components of a particular distro, such as the package-manager itself, might be written in Perl.   Thus, even a “slight” change to the packaged Perl distribution might introduce “breaking changes” with many repercussions.   It should also be considered that, when any change is made to the language interpreter, most if not all packages for that interpreter might have to be updated and/or recompiled.   The “ripple effects” can be quite substantial.