Is there a concerted effort to break CPAN for older perl versions to drive support for v7?

[Anonymous Monk]

It's not that big a deal when new dists require a higher minimum perl version. But when a member of the steering committee bumps the required minimum versions of most of his many dists to 5.12, for no technical reason that's a bad sign. And many of his dists are upstream, so he's effectively forcing all dists that depend on his to also have an artificial minimum required perl version than is necessary. His self-contradictory rationale:

This library should run on perls released even a long time ago. It should work on any version of perl released in the last five years. Although it may work on older versions of perl, no guarantee is made that the minimum required version will not be increased. The version may be increased for any reason, and there is no promise that patches will be accepted to lower the minimum required perl.

Now I just noticed that File::Rename is also preparing to bump it's min rquired perl version. From the README from it's newest release:

This release is a step towards C<use v5.32> or C<use v7> compatibilty

That dist might not be upstream, but it's heavily referenced on many sites. Is increasing the minimum required perl version a step towards breaking the tradition of backwards compatibility and paving the way for the breaking changes that v7 advocates were championing?

[choroba]

Would have been great if you had included a link to the article you were citing from so readers could have the full picture.

Also, why do you think it's a bad sign? Why do you think it's not necessary?

This is not a question, this is a rant disguised as a question.

[Anonymous Monk]

Different dude here. I says if ya can update 116 distros to bump minimum version, ya can put up a bundle/snapshot/index so that info is known, ... Some kind of magic for muggels who'll turn here for help running some ol software ... What was that thing cpXXXan? Some kind of cpan -for5.8.8 Foo that installs Foo from time 5.8.8 was released? Wow time flies

[choroba]

Anyone can do it. And yes, someone did it, and the article I linked to that was the initial reason this thread started even mentions it. Good idea for anyone hankering for recognition in the Perl circles. Asking David Cantrell (here as drhyde) or checking https://github.com/MorayJ/cpXXXan for the details might save you some work.

But as nobody took over the site, maybe it wasn't that urgent for anybody?

[haj]

Are there any technical reasons to request support for Perl 5.10 or older?

Bumping the minimum Perl version is a reasonable thing to do regularly and should be considered whenever a new Perl version is released. The new minimum version is 5.12, which was released more than 12 years ago. So, there is no contradiction in the rationale.

An obvious technical reason for bumping the minimum version is to limit the number of different versions for testing new releases. Also, CPAN authors might want to use features which have been added to the Perl core at some point in time.

So, to answer the question raised in your subject: This can be construed to be a concerted effort to break CPAN for older Perl versions. Older than 12 years, to be precise. The process is called software maintenance. However, it has nothing to do with driving support for V7, whatever that might turn out to be.

[hippo]

But when a member of the steering committee bumps the required minimum versions of most of his many dists to 5.12, for no technical reason that's a bad sign. And many of his dists are upstream, so he's effectively forcing all dists that depend on his to also have an artificial minimum required perl version than is necessary.

But that's only for the newest versions of his modules. You don't have to use the newest version of them just like you don't have to use the newest version of Perl. If you want to run 5.10 that's up to you - having to work a tiny bit harder to ensure you use compatible versions of modules is only to be expected, no?

FWIW, I think that dropping active support for perl versions which are no longer shipped with any pre-EOL O/S seems perfectly reasonable.

[Tux]

This medal has two sides. You only look at the backward compat issues. A developer or maintainer can be seriously hindered in two ways:

• Maintaining backward compatibility preventing use of new features
• Future compatibility preventing support for older perls

The step you describe here is most likely a stepping stone to implementation of new features that are only possible in 5.12 and up.

If you depend on a module that works FINE on the current (old) perl and does not have a security issue, why do you expect the author of that module to support 13 year old perl builds? Seriously, you are just saying that this old perl is *more* important than current or upcoming builds. What would your argument be to someone complaining that this module does not work on perl-5.37.8 with the features it promotes?

There are numerous reasons to stick to old perls, as there are numerous reasons to require a minimum version in production environments (to me that is 5.014002), and there are also numerous reasons to draw a line and require a minimuum version just to be able to go forward and support the current state of affairs.

For me the coin mostly drops in supporting old perl versions as my modules are quite high in the CPAN river, but I won't rule out that someday, I will also raise the bar to make development easier.

One more addition: stating a minimum version to authors that test their distro on all supported versions means they also need access to that version. Not all developers have 500+ prebuilt perl versions available. Sometimes you can ignore the minimum version and just build with the version you have. Sometimes you cannot.

merged edited addition: If an author states a minimum version, it might be the lowest version he/she has access to for testing. You might get away with an older version, but the author cannot guarantee it. YMMV. Additionally, they author might find a feature compelling enough to require the version it was introduced in. The end-user that still wants to use their module might be able to rewrite those to something supported in the version they want to support (like $a = $b // $c → $a = defined $b ? $b : $c;)

[kcott]

This node has been considered for reaping. The reason given is:

"earlier duplicate of Re: Is there a concerted effort to break CPAN for older perl versions to drive support for v7? (the second has additional text, so reap this earlier node)"

• Both nodes have the same opening paragraphs.
• The node to keep has a final paragraph which starts with "edited addition: ..."
• The node to reap has a final paragraph which starts with "One more addition: ..."

Those two final paragraphs are different; one does not simply represent "additional text".

It would make sense to merge those two different paragraphs into one of the nodes, then reap the other node.

At this point, I'm not voting "reap" on either node.

Edit (afterthought): I think the consideration should be removed until the issue I've described is resolved.

[Anonymous Monk]

I will also raise the bar to make development easier.

Got a good example(s)? The blog in question made a philosophical stance

[cavac]

Got a good example(s)?

Better boolean support in Perl 5.36

Also:

The 5.36 bundle enables the signatures feature. Introduced in Perl ver
+sion 5.20.0, and modified several times since, the subroutine signatu
+res feature is now no longer considered experimental. It is now consi
+dered a stable language feature and no longer prints a warning.

[tobyink]

This question assumes that there are is a significant population of users, who:

• Really want to use the latest version of RJBS's modules, but also
• Will not use any version of Perl released in the last decade.

[Anonymous Monk]

And what technical reason do you have for needing someone to support a Perl version more than 13 years old? Are you paying them anything?

BackPAN exists. If you're stuck on an ancient Perl, you're stuck with older versions of modules.

It's free & open source software. Instead of whining, spend your energy on fixing your (perceived) problem instead.

[Tux]

This medal has two sides. You only look at the backward compat issues. A developer or maintainer can be seriously hindered in two ways:

• Maintaining backward compatibility preventing use of new features
• Future compatibility preventing support for older perls

The step you describe here is most likely a stepping stone to implementation of new features that are only possible in 5.12 and up.

If you depend on a module that works FINE on the current (old) perl and does not have a security issue, why do you expect the author of that module to support 13 year old perl builds? Seriously, you are just saying that this old perl is *more* important than current or upcoming builds. What would your argument be to someone complaining that this module does not work on perl-5.37.8 with the features it promotes?

There are numerous reasons to stick to old perls, as there are numerous reasons to require a minimum version in production environments (to me that is 5.014002), and there are also numerous reasons to draw a line and require a minimuum version just to be able to go forward and support the current state of affairs.

For me the coin mostly drops in supporting old perl versions as my modules are quite high in the CPAN river, but I won't rule out that someday, I will also raise the bar to make development easier.

One more addition: stating a minimum version to authors that test their distro on all supported versions means they also need access to that version. Not all developers have 500+ prebuilt perl versions available. Sometimes you can ignore the minimum version and just build with the version you have. Sometimes you cannot.

merged edited addition: If an author states a minimum version, it might be the lowest version he/she has access to for testing. You might get away with an older version, but the author cannot guarantee it. YMMV. Additionally, they author might find a feature compelling enough to require the version it was introduced in. The end-user that still wants to use their module might be able to rewrite those to something supported in the version they want to support (like $a = $b // $c → $a = defined $b ? $b : $c;).

[cavac]

As for me, i only use Perl versions that are still maintained. For some stuff, i decide early on that i want to use certain features of the latest version of Perl.

I know this might sound a bit harsh, but life is too short. If you want to run the latest versions of my published modules on a 12+ year old, unsupported version of Perl, why should i have the burden of backporting and testing against a Perl version that i will never again use for myself (and have banned from my systems because of all the unfixed security bugs). I would certainly be willing to explain what parts of my code do to help you make that backport. But otherwise, i'd rather spend my time writing new code and enhancing existing one.

I'm a software developer, not a museum curator.

[parv]

Ha! Only if! Perl v7 was not going to be any more than different than current 5.34 (is 5.36 out?) AFAIAC; last time when I had cared enough to regularly read p5p mailing list on the subject, got the impression that besides a number change, nothing much would materially change💩

[WithABeard]

Seems to me that v7 is more about formalizing a predictable process for making deprecations and other breaking changes (especially to the defaults). The changes in v8 will probably be of more significance.

One significant change though, is that new users can use all the latest features without knowing or caring what the defaults were 15 years ago. Lowering the bar for newcomers is a very welcome change.

[Anonymous Monk]

As both a maintainer of existing code and a dev for new projects, God, I hope so.

You're talking about a version of perl that will be 13 years old in April. When perl 5.12.0 was released, the current OS from Microsoft was Windows 7. The first iPad was released just nine days earlier. Android was still at version 2.something and was still the odd OS trying to eat away at Symbian's lead. The LTS release of the Linux kernel that was valid back then hit EOL in 2016. Moose v1.0 wasn't even a month old. If your boss came to you and demanded you write software that targeted any of those today, you'd think they got hit on the head with something pointy.

The Perl language has changed so much and enough bugs in perl itself have been fixed in that time that, for my own projects, I wouldn't consider burning too much time even testing against anything older than two maintenance track (typically even numbered) releases; at the moment, that would be perl 5.32 which is already nearly 3 years old.

In short, I'm more than okay with leaving the past in the past. However, I would also consider that a breaking change that might get a major version bump to the dist itself in a release that only includes that new minimum perl version metadata and/or use v5.xx; line. That's just smart deprecation policy.

[Anonymous Monk]

I am surprised in the Perl community how common it is to run out of date versions of Perl.

Correct me if I'm wrong, but it seems to me that any version of perl prior to 5.30.3 is insecure (in that it would have unpatched CVE's).

Anyone using Perl for any semi-serious purpose should have tests in there release chain to assist in upgrading to the newest version of Perl at a moments notice - as a new version of a CVE could be discovered at any time.

Perl itself (at least for 5.x) is meant to be backwards compatible as well. I can't remember the last time I moved perl up and had a single compatibility issue even with my products using hundreds and hundreds of CPAN modules. I believe the last time was around 5.16'ish when Perl arguably broke backwards compatibility by changing some behaviors of the Perl API which impacted AnyEvent.

[hippo]

Correct me if I'm wrong, but it seems to me that any version of perl prior to 5.30.3 is insecure (in that it would have unpatched CVE's).

Yes and no. If you are installing it yourself from source, then yes. OTOH, I expect that most users will install from their distro's packages and these do get backported fixes while the distro itself is still supported. Thus you will see updates for example for the Perl v5.16.3 which shipped with CentOS 7 still being provided. So long as your distro is still shipping updates you can consider your old Perl to be safely usable.

I can't remember the last time I moved perl up and had a single compatibility issue even with my products using hundreds and hundreds of CPAN modules.

The 2 recent(ish) big breaks for me were the removal in 5.18 of '.' from @INC and the breakage in 5.14 of for my $i qw/foo bar/ { print "$i\n"; }. The former was well advertised, had a good rationale and an easy workaround if required. The latter less so.